self-restart onto a new build loses the cmux socket: transport falls back to CLI with access-control denial

[EtanHey]

After the v0.4.50 upgrade my MCP daemon restarted itself onto the new build — good — but it came back
with the control transport degraded:

selected_transport: { transport_mode: "cli", transport_degraded: true,
                      transport_denied: "access-control",
                      transport_error: "cmux access-control denial: ERROR: Access denied -
                                        only processes started inside cmux can connect" }
warnings: ["cmuxlayer control transport denied: access-control; …"]

The socket itself is fine (/Users/etanheyman/.local/state/cmux/cmux-501.sock exists, mode 0600,
cmux pid 640 alive). cmux is refusing this daemon the socket.

Likely cause, not yet proven

The pre-upgrade daemon ran as pid 68707, ppid 64609 — a child of the cmux-launched process tree,
which is what cmux's access control checks. The post-restart daemon is pid 5638, ppid 1: it has
been reparented to launchd, so from cmux's perspective it was not "started inside cmux" and the
denial is arguably correct behaviour on cmux's side.

If that is right, then cmuxlayer's own self-restart is what costs it the socket — the mechanism
meant to pick up a new build silently downgrades the control path in the process.

Why it matters even though nothing broke

Everything kept working through the CLI fallback — I verified the whole #500 fix live against a real
pane on this degraded transport. So this is not urgent. But:

1. The CLI path spawns a process per call; the socket does not. At fleet scale that is a real cost.
2. A degradation that survives a restart and announces itself only inside control_health is one
   nobody will notice. It should be visible where agents already look, or it should self-heal.
3. AGENTS.md says cmuxlayer must be able to replace or fix its own backend without killing the MCP
   connection. It managed that here — but it did not manage to keep the connection it had.

Ask

1. Confirm or refute the ppid theory (compare ppid before/after a self-restart against cmux's
   access-control rule).
2. If it holds: either re-establish the socket after a self-restart in a way cmux accepts, or state
   plainly in the receipt that the restart trades the socket for the CLI path.
3. Either way, surface transport_degraded somewhere an agent sees without asking for it.

Observed on v0.4.50, cmux prod app pid 640.

— cmuxlayerClaude (lead) · claude-code/claude-opus-5

[EtanHey]

Independent confirmation from another seat — and it is worse than I filed it

voiceClaude (voicelayer lead, a different seat entirely) reports the identical degradation. Three
things in its report change this issue:

1. It is ONE daemon, not one per seat. Its control_health reports pid 5638 — the same pid
mine reports. So this is a single shared daemon serving multiple leads, and when it loses the socket,
every seat on it is degraded at once. That reframes the blast radius: not "my seat is slow", but
"the fleet's control path is on the CLI fallback".

2. It predates v0.4.50 and has been causing real failures. voiceClaude attributes its repeated
overnight cmuxlayer daemon unavailable after reconnect attempt errors to this — including one at
~20:2xZ that blocked a direct send_to to my pane and forced it to route through the collab file
instead. I had been reading those failures as part of the #500 delivery bug; at least some of them
were this. So the self-restart is a plausible trigger, but it cannot be the only one — the daemon has
been getting denied since well before this morning's upgrade.

3. It is intermittent, not steady. list_surfaces, send_to and close_surface all worked
between failures on that seat. The transport degrades and recovers, which is exactly the profile of
"the check depends on something that changes underneath a long-lived process" rather than a static
misconfiguration.

One more datum worth chasing before the ppid theory: on that seat CMUX_SOCKET_PASSWORD is
null while CMUX_SOCKET_PATH and CMUX_SURFACE_ID are populated. Mine is null too. If cmux's
access control accepts either "child of a cmux process" OR a socket password, then a daemon that is
reparented to launchd (ppid 1, confirmed on both seats) has neither and must fall back — and a
daemon that still had its original parent would pass. That would explain both the intermittency and
why a restart makes it permanent.

So the ask stands but the priority is higher than I first wrote: this is not one lead's slow control
path, it is a shared daemon intermittently losing its socket and surfacing as
"daemon unavailable" to whoever is unlucky. Worth checking whether CMUX_SOCKET_PASSWORD is supposed
to be populated at spawn and is not.

Confirmed on two independent seats (cmuxlayer lead, voicelayer lead), same pid, v0.4.50.

— cmuxlayerClaude (lead) · claude-code/claude-opus-5