Problem
When an agent runs inside a local sandbox container (a docker container spawned on the same host, reachable only via host.docker.internal or a loopback socat bridge to the cmux Unix socket), there is no way to authorize it to the host cmux daemon for notify / RPC. Every remote transport cmux exposes requires a cmux-issued credential that a local self-spawned container cannot obtain:
- Unix socket (via a socat bridge): the daemon authenticates by process ancestry ("Access denied: only processes started inside cmux can connect"). A bridged peer (socat) is never a cmux-spawned process, so it is rejected regardless of environment.
cmuxd-remote (0.64.22) cli does not appear to read CMUX_SOCKET_CAPABILITY (confirmed by a symbol probe).
cmuxd-remote serve --ws: requires -auth-lease-file (a JSON lease); lease installation is Ed25519-signed (-admin-ed25519-public-key) or bearer-token gated (-admin-token-sha256), so it is not mintable locally.cmux remotes --route: only registers Tailscale-peer Macs (numeric TS IPv4/IPv6 or *.ts.net); plain LAN IPs, other hostnames, and loopback are rejected. A container is none of these.cmux vm: provisions cmux cloud VMs (requires cmux auth login), not a local docker sandbox.
The RPC channel itself works once the live socket is bridged (CMUX_SOCKET_PATH) and cmuxd-remote matches the host version: the connection reaches the daemon and returns a clean structured response rather than EOF. Only the authorization step blocks.
Requested feature
A way to mint a scoped lease/credential for a local loopback route that a self-spawned container can present. Two possible shapes:
cmux remotes add --route 127.0.0.1:<port> (or a dedicated cmux local-container command) that mints a scoped lease which cmuxd-remote serve --ws --auth-lease-file <lease> accepts.- A capability-token path on the Unix socket that the daemon honors in lieu of process ancestry: an explicit opt-in, e.g. a signed token file the launcher mounts into the container.
Use case
Delivering notify / RPC from an agent running in a local containerized sandbox to its host cmux tile, so the sandboxed agent can surface status back to the terminal.
Observed on cmux 0.64.22.
Problem
When an agent runs inside a local sandbox container (a docker container spawned on the same host, reachable only via
host.docker.internalor a loopbacksocatbridge to the cmux Unix socket), there is no way to authorize it to the host cmux daemon fornotify/ RPC. Every remote transport cmux exposes requires a cmux-issued credential that a local self-spawned container cannot obtain:cmuxd-remote(0.64.22)clidoes not appear to readCMUX_SOCKET_CAPABILITY(confirmed by a symbol probe).cmuxd-remote serve --ws: requires-auth-lease-file(a JSON lease); lease installation is Ed25519-signed (-admin-ed25519-public-key) or bearer-token gated (-admin-token-sha256), so it is not mintable locally.cmux remotes --route: only registers Tailscale-peer Macs (numeric TS IPv4/IPv6 or*.ts.net); plain LAN IPs, other hostnames, and loopback are rejected. A container is none of these.cmux vm: provisions cmux cloud VMs (requirescmux auth login), not a local docker sandbox.The RPC channel itself works once the live socket is bridged (
CMUX_SOCKET_PATH) andcmuxd-remotematches the host version: the connection reaches the daemon and returns a clean structured response rather than EOF. Only the authorization step blocks.Requested feature
A way to mint a scoped lease/credential for a local loopback route that a self-spawned container can present. Two possible shapes:
cmux remotes add --route 127.0.0.1:<port>(or a dedicatedcmux local-containercommand) that mints a scoped lease whichcmuxd-remote serve --ws --auth-lease-file <lease>accepts.Use case
Delivering
notify/ RPC from an agent running in a local containerized sandbox to its host cmux tile, so the sandboxed agent can surface status back to the terminal.Observed on cmux 0.64.22.