MGS2008: daemon socket withheld from subprocesses

The daemon socket vars (MAGUS_DAEMON_SOCKET, MAGUS_DAEMON_ADDRESS) are magus's own pool pointers. magus withholds them from every op subprocess and re-hands them only to a nested magus. This code is logged, at debug level only, on both halves of that contract: when a var is withheld from a child, and when it is re-injected for a legitimate recursive magus invocation.

[MGS2008] withheld magus daemon pointer(s) from op subprocess (done regardless of sandbox.enabled) (see https://github.com/egladman/magus/blob/main/docs/codes/sandbox/MGS2008.md)
  vars=[MAGUS_DAEMON_SOCKET]
[MGS2008] daemon socket injected into recursive magus invocation
  var=MAGUS_DAEMON_SOCKET

Why

The daemon socket is unauthenticated: anything that can reach it can drive the daemon. If those vars were inherited by every child, a compromised third-party spell could connect to the daemon and issue commands. So magus strips them from every op subprocess, alongside the other secret-bearing vars (see MGS2003.md).

This withholding is independent of sandbox.enabled. With the sandbox on, the vars are simply absent from the environment allowlist. But the sandbox is off by default, and "off" rebuilds no environment - the child would otherwise inherit the whole parent environment - so magus carries the withholding in an explicit code path that runs either way. That is why turning the sandbox off does not hand these pointers to spells, and why they can go missing from a subprocess even in a workspace with no sandbox configured at all.

A nested magus call is the one exception. It is a recursive invocation of the same trusted binary, and it genuinely needs the daemon to coordinate. For that case magus re-injects MAGUS_DAEMON_SOCKET and MAGUS_DAEMON_ADDRESS as explicit env overrides on the child, and records it with this code.

The log fires at debug (-v), not info, because a run spawns many ops (and a fan-out many recursive invocations) and it would otherwise be pure noise at default verbosity. It is an internal correctness note, not an error and not user-actionable.

Resolution

Nothing to do. This is the sandbox working as intended: the socket stays hidden from spell subprocesses, and is handed only to nested magus processes that need it.

If a subprocess of yours genuinely needs to reach the daemon and cannot see the socket, that is this rule at work - a plain program is not a nested magus and is not trusted with the unauthenticated socket. Reach for the pointer through a recursive magus call instead. The withheld line explains a missing var; the already running under a parent magus error, which now names the inherited MAGUS_DAEMON_SOCKET, explains the opposite case where a program mistook the inherited socket for adoption.

You will see these lines only when running at -v or higher. If you do not want the noise, run at default verbosity.