Fix the director SOCKS proxy hostname and Docker alias contract #1529

New issue

Closed

opened 2026-07-23 06:51:41 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-07-23 06:51:41 +00:00

Member

Incident

A live read-only director had all of the nominal sidecar wiring but could not resolve the proxy hostname:

The director container was attached to Docker network ward-tailnet.
WARD_TS_SOCKS5 named host tailscale-proxy.
The standing proxy container was mac-proxy, with Docker network aliases mac-proxy and tailscale.
Requests failed with Could not resolve host: tailscale-proxy.

Closed #1494 renamed the default proxy hostname to tailscale-proxy, but the live network alias assignment did not follow the value exported into the director. Open #1495 is the broader Tailscale-awareness removal. This issue is the narrower transport invariant that must remain correct through that cleanup.

Expected contract

The hostname exported in WARD_TS_SOCKS5 resolves from every sidecar-enabled agent and director.
Use one stable canonical Docker network alias for the current contract: tailscale-proxy.
Compute or source the environment hostname and proxy-container alias from the same authoritative value so they cannot drift.
Add a regression test that connects the computed environment hostname to the aliases assigned to the standing proxy.
Cover both director and engineer launch-plan paths that enable the sidecar.
Preserve the current userspace proxy model with no TUN device and no NET_ADMIN.

Scope boundaries

This is generic proxy and Docker-network transport plumbing. Do not add Kubernetes behavior, kubeconfig handling, credentials, cluster policy, or a second proxy lifecycle. Do not broaden credential visibility. Coordinate naming cleanup with #1495 without weakening the hostname-to-alias invariant.

## Incident A live read-only director had all of the nominal sidecar wiring but could not resolve the proxy hostname: - The director container was attached to Docker network `ward-tailnet`. - `WARD_TS_SOCKS5` named host `tailscale-proxy`. - The standing proxy container was `mac-proxy`, with Docker network aliases `mac-proxy` and `tailscale`. - Requests failed with `Could not resolve host: tailscale-proxy`. Closed #1494 renamed the default proxy hostname to `tailscale-proxy`, but the live network alias assignment did not follow the value exported into the director. Open #1495 is the broader Tailscale-awareness removal. This issue is the narrower transport invariant that must remain correct through that cleanup. ## Expected contract - The hostname exported in `WARD_TS_SOCKS5` resolves from every sidecar-enabled agent and director. - Use one stable canonical Docker network alias for the current contract: `tailscale-proxy`. - Compute or source the environment hostname and proxy-container alias from the same authoritative value so they cannot drift. - Add a regression test that connects the computed environment hostname to the aliases assigned to the standing proxy. - Cover both director and engineer launch-plan paths that enable the sidecar. - Preserve the current userspace proxy model with no TUN device and no `NET_ADMIN`. ## Scope boundaries This is generic proxy and Docker-network transport plumbing. Do not add Kubernetes behavior, kubeconfig handling, credentials, cluster policy, or a second proxy lifecycle. Do not broaden credential visibility. Coordinate naming cleanup with #1495 without weakening the hostname-to-alias invariant.

coilyco-ops closed this issue

2026-07-23 06:55:35 +00:00

coilyco-ops referenced this issue

2026-07-23 06:56:07 +00:00

Delete Ward’s obsolete Tailnet transport stack #1495

coilyco-ops commented

2026-07-23 07:23:48 +00:00

Author

Member

WARDED_WORKFLOW: reservation-released

release details

Run never started. ward container reap released container engineer-codex-ward-1529 (--harness codex): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the launch intent it took is retracted. Nothing is running on this issue. It needs re-dispatch. A ward agent director re-queues it automatically. A manual ward agent retry no longer needs --override-reservation.

— Codex, via ward agent

WARDED_WORKFLOW: reservation-released <details><summary>release details</summary> Run never started. `ward container reap` released container `engineer-codex-ward-1529` (`--harness codex`): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the launch intent it took is retracted. Nothing is running on this issue. It needs re-dispatch. A `ward agent director` re-queues it automatically. A manual `ward agent` retry no longer needs `--override-reservation`. </details>  — Codex, via `ward agent`

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/ward#1529

No description provided.

Rows
Columns