`sonar run mcp` cannot reach a self-hosted SonarQube: container gets no `--network`, so `localhost` resolves to the container itself

CLI version

1.7.0

Operating system and version

Windows 11

Command you ran

sonar run mcp

What happened

`sonar run mcp` launches the MCP server container without any `--network` argument, so it lands on the container runtime's default bridge network. It is then passed `SONARQUBE_URL` verbatim from the stored connection. When that URL is `http://localhost:9000` — the normal value for a self-hosted server reachable on the host's loopback — `localhost` inside the container's own network namespace refers to the container, not the host. The server fails to start.

Because the container also runs under `--rm`, it removes itself immediately on failure, so it never appears in `podman ps -a` / `docker ps -a` and the failure is easy to misread as "the MCP server silently did nothing".

There is no flag to control this: `sonar run mcp --help` offers only `--debug`, `--read-only`, `--toolsets` and `--project`.

What you expected to happen

Environment

• sonarqube-cli 1.7.0
• SonarQube Server 26.9.0.129388 (Community Build), running as a container
• Container runtime: podman 6.1.1 on Windows 11 (WSL2 backend), invoked through a docker-named shim
• Agent: Claude Code

Steps to reproduce

1. Run SonarQube Server in a container on a user-defined network, published to the host loopback only:

   podman network create sonar-net
   

INFO SonarQube MCP Server - SonarQube MCP Server Started:
INFO SonarQube MCP Server - Transport: stdio
INFO SonarQube MCP Server - URL: http://sonarqube:9000
INFO SonarQube MCP Server - All tools loaded: 29 tools

Impact

Any self-hosted SonarQube reachable only on the host lor run mcp on a runtime without Docker Desktop'shost.docker.internal` behaviour.

sonar integrate claude reports complete success, so tr as an agent with no mcp__sonarqube__* tools — withno obvious link back to container networking. Notably, sonar analyze and the containerised scanner path are unaffected, because those let the caller control networking.

Suggestions

1. Expose a --network (and ideally --add-host) pass
2. Or, when the stored URL is loopback, add --network host automatically (or --add-host=host.docker.internal:host-gateway on Linux/podman) rather than relying on Docker Desktop's implicit behaviour.
3. Or, at minimum, fail loudly at sonar integrate tims container networking as the cause — the currentfailure is silent and self-erasing due to --rm.

Additional context

No response

Start at the sonar run mcp entry point and inspect how it launches the MCP container, including the --rm behavior; compare it with the networking options used by sonar analyze and the containerised scanner path. Done means a self-hosted SonarQube at a host-loopback URL can be reached on the reported runtime, and failures are no longer silent.