Windows CLI 2.111.0: `supabase db start` hangs silently before contacting Docker

[Brunoake]

Bug report

Description

On Windows 10, Supabase CLI 2.111.0 hangs indefinitely when running supabase db start. The command emits no output, even with --debug, and appears to stop before contacting Docker.

This was reproduced both in an application repository and in an isolated empty temporary project.

Steps to reproduce

1. Create an empty temporary directory.
2. Initialize it:

   supabase init --workdir . --yes

3. Use otherwise default local config, changing only the database/shadow ports to unused ports and disabling the seed.
4. Run:

   supabase db start --workdir . --debug --agent no

5. Observe that the process remains alive but silent until terminated externally.

I also repeated the test with a process-local Docker API override:

$env:DOCKER_API_VERSION = "1.44"
supabase db start --workdir . --debug --agent no

The behavior was unchanged.

Expected behavior

The local Postgres service should start, or the CLI should return an actionable error.

Actual behavior

• No stdout or stderr, including with --debug
• Process remains responsive and consumes about one second of CPU time
• No TCP connection is opened by the CLI process
• The configured database port remains free
• No Docker container, network, or volume is created for the project
• Docker itself is responsive (docker version succeeds)
• Default isolated run was terminated after approximately 124 seconds
• The DOCKER_API_VERSION=1.44 run was terminated after approximately 94 seconds

Because the CLI never returns an error, --create-ticket cannot be reached.

Environment

• OS: Microsoft Windows 10 Pro, version 10.0.19045, build 19045
• Supabase CLI: 2.111.0 (@supabase/cli-windows-x64)
• Docker Desktop: 4.82.0 (233772)
• Docker client/engine: 29.6.1
• Docker context: desktop-linux
• Docker API: client/server 1.55; server minimum 1.40
• Docker backend kernel: WSL2
• Supabase local Postgres major version: 17
• Project: empty, unlinked, with no migrations, credentials, or remote Supabase access

An explicit Docker named-pipe host was also tested previously without changing the result.

Additional context

All test resources were isolated and removed afterward. No Docker resources were created during the hanging command. A comparison with CLI 2.110.0 could not be completed because downloading that version stalled, so no conclusion was drawn from that attempt.

Please let me know if there is a supported trace mechanism beyond --debug that would help identify where the Windows process is blocking.