Originally planned as an e2e scenario that runs a tiny Go program (using `github.com/docker/docker/client`) inside a container bind-mounting `~/.gocker/gocker.sock`, to exercise the API end-to-end with the real Docker SDK.
Why it's blocked
Apple Container CLI's virtiofs mount passes the socket file's inode across to the container, but AF_UNIX `connect()` on the resulting file inside the container doesn't flow through to the host's socket server. Virtiofs is a file protocol, not a socket bridge. Discovered on 2026-04-23 during the UX regression guards work — the scenario was implemented, got as far as "Cannot connect to the Docker daemon at unix:///host-gocker/gocker.sock", and was removed.
Options
- Expose the daemon on a TCP loopback socket in addition to (or instead of) Unix. Then the container connects over `tcp://host.internal:` which virtiofs has nothing to do with.
- Run the harness on the host as a Go test rather than a compose scenario. Loses the "real SDK in a real container" flavor but still exercises the same wire protocol.
What we already have
Shape-level SDK compat is covered by `api/docker_compat_test.go` — every JSON-returning endpoint decodes into the real `github.com/docker/docker` SDK types (`types.NetworkResource`, `volume.Volume`, `container.CreateResponse`, `types.DiskUsage`, `events.Message`, etc.). That's the most important layer of protection and it's in place.
This issue is about adding a live-wire harness on top of that, not replacing it.
Originally planned as an e2e scenario that runs a tiny Go program (using `github.com/docker/docker/client`) inside a container bind-mounting `~/.gocker/gocker.sock`, to exercise the API end-to-end with the real Docker SDK.
Why it's blocked
Apple Container CLI's virtiofs mount passes the socket file's inode across to the container, but AF_UNIX `connect()` on the resulting file inside the container doesn't flow through to the host's socket server. Virtiofs is a file protocol, not a socket bridge. Discovered on 2026-04-23 during the UX regression guards work — the scenario was implemented, got as far as "Cannot connect to the Docker daemon at unix:///host-gocker/gocker.sock", and was removed.
Options
What we already have
Shape-level SDK compat is covered by `api/docker_compat_test.go` — every JSON-returning endpoint decodes into the real `github.com/docker/docker` SDK types (`types.NetworkResource`, `volume.Volume`, `container.CreateResponse`, `types.DiskUsage`, `events.Message`, etc.). That's the most important layer of protection and it's in place.
This issue is about adding a live-wire harness on top of that, not replacing it.