Document --host for non-loopback headless connections

[SteveSandersonMS]

The headless CLI server binds to 127.0.0.1 by default, so connections from other machines or containers fail unless --host is set. Document this in the getting-started guide and backend-services setup, and update the Docker, Docker Compose, Kubernetes, and Azure Container Instances examples to pass --host 0.0.0.0 (which is required for any container with a published port).

Also fix the container-proxy bundling scenario, which used a non-existent --bind flag instead of --host.

Fixes #1153

[Copilot]

Pull request overview

Updates documentation and container examples to ensure headless Copilot CLI servers are reachable from non-loopback clients by explicitly binding with --host (not the non-existent --bind), addressing remote/container connection failures (Issue #1153).

Changes:

• Document that headless mode binds to loopback by default and requires --host for remote/container access.
• Update Docker / Docker Compose / Kubernetes / Azure Container Instances examples to pass --host 0.0.0.0.
• Fix the container-proxy bundling scenario to use --host instead of --bind.

Show a summary per file

File	Description
test/scenarios/bundling/container-proxy/README.md	Fixes the documented CLI flag for container binding (--host).
test/scenarios/bundling/container-proxy/Dockerfile	Updates the runtime ENTRYPOINT to use --host 0.0.0.0.
docs/setup/scaling.md	Updates K8s + ACI examples to bind headless CLI on all interfaces.
docs/setup/backend-services.md	Adds guidance and updates container examples to pass --host 0.0.0.0.
docs/getting-started.md	Adds loopback default explanation and security warning for non-loopback binding.

Copilot's findings

Comments suppressed due to low confidence (1)

docs/setup/backend-services.md:88

• The systemd example still starts the CLI without --host, which means it will keep binding to loopback only. That contradicts the preceding guidance about accepting connections from other hosts and can lead to the same “remote client can’t connect” failure. Consider either adding --host 0.0.0.0 to the systemd ExecStart, or explicitly calling out that --host is only needed when the SDK will connect from a different machine/container.

For production, run it as a system service or in a container:

```bash
# Docker — must bind to 0.0.0.0 so the container's published port is reachable
docker run -d --name copilot-cli \
    -p 4321:4321 \
    -e COPILOT_GITHUB_TOKEN="$TOKEN" \
    ghcr.io/github/copilot-cli:latest \
    --headless --host 0.0.0.0 --port 4321

# systemd
[Service]
ExecStart=/usr/local/bin/copilot --headless --port 4321

• Files reviewed: 5/5 changed files
• Comments generated: 1

[Copilot]

This section recommends binding to 0.0.0.0 for non-loopback access, but it doesn’t include the security warning that appears in getting-started.md. Since 0.0.0.0 exposes the JSON-RPC port broadly, it would be good to add a brief warning here as well (firewall/private network/reverse proxy, etc.).

This issue also appears on line 76 of the same file.

See below for a potential fix:

> [!WARNING]
> Binding to `0.0.0.0` exposes the JSON-RPC port on all network interfaces. Only do this on a trusted private network, or protect it with a firewall, reverse proxy, or similar network controls.

For production, run it as a system service or in a container. If you bind to `0.0.0.0`, make sure the port is not exposed broadly without firewalling or other access controls:

```bash
# Docker — bind to 0.0.0.0 so the container's published port is reachable, but only expose the published port on a trusted network or behind a firewall/reverse proxy