The mutex was visible, but the pipe wasn't

Debugging a Unity launch that only failed inside the Codex sandbox, and why "works on my machine" now describes more than one machine.

August 2026

A coding agent used to be a thing that edited files. Now it launches compilers, game engines, browsers, containers, simulators and signing tools, and it launches them from inside its own security context. That context can share your machine, your files, your username and your process table while quietly holding different effective capabilities. Which means "works on my machine" no longer describes one environment. It describes at least two, and one of them is the agent's.

This is the story of the first time that difference cost me real hours, what finally discriminated the cause, and the general shape of the trap so you can recognise it faster than I did.

!The incident

I asked Codex to run the project. It invoked Unity, and Unity sat in licensing and never came up. The logs pointed firmly away from the agent: the licensing channel was refused, initialisation timed out repeatedly, and everything read like a licensing outage or a wedged local licensing service.

The same Unity installation, opening the same project, launched interactively from the desktop: fine. Every time.

?Why the logs were convincing

The failure logs contained a pile of individually accurate, collectively misleading signals (excerpts redacted and paraphrased):

• connection to licensing channel refused
• global mutex already held, suggesting another licensing process owned the resource
• repeated timeout waiting for licensing module initialisation
• a warning about a missing headless entitlement

Each of these supports a tidy story: the licensing backend is down, or a local service is wedged and holding the mutex, or the account lacks a headless licence. I chased each one. The trap is that similar warnings also appear during successful launches. A noisy subsystem that grumbles on the happy path gives you an inexhaustible supply of plausible causes on the unhappy one.

ΔThe discriminating experiment

The move that broke the loop was to stop reading failure logs in isolation and diff them against success logs. I collected logs from interactive host launches that worked and Codex launches that didn't, discarded every message that appeared in both, and looked at what was unique to the failures.

One thing survived the diff: in the restricted executions, a query for host identity through Windows Management Instrumentation (WMI) was denied. Host launches made the same query and it succeeded.

So I pulled that into a preflight probe and ran the identical probe in both contexts: once inside the Codex sandbox, once interactively. Same machine, same user, same files.

=What was actually observed

Those are the observed facts. Everything above the WMI row is identical between the two contexts, which is exactly why the logs were so persuasive: nearly everything the licensing code could see looked normal from inside the sandbox.

~The likely mechanism

What follows is inference, and I want to label it as such, because I did not disassemble Unity's licensing client and the internals here are inferred from the boundary behaviour, not read from source.

The sandbox shares enough of the host that discovery works: the licensing client can see the global mutex, the files, the installed licence artefacts. But the supporting capabilities are not equally accessible. The host-identity query is denied, and the inter-process communication (IPC) the licensing flow depends on appears to be unusable or unreliable across the sandbox boundary. Entitlement resolution fails before it really begins.

Partial visibility is the poison. If the sandbox hid everything, the failure would be obvious and immediate. Because it shows you the mutex but not a working pipe, every individual log line is true and the overall story they tell is wrong. The mutex was visible. The pipe wasn't.

✓The fix

The fix was not a licensing fix. It was to treat the Codex execution context as a first-class environment with its own known behaviour:

• Probe before launching. The launch script now runs the cheap WMI host-identity check before starting Unity. Denied means don't launch a multi-minute editor boot that is guaranteed to die in licensing.
• Fail with an agent-specific explanation. The error says "you are in a restricted execution context and Unity licensing will not resolve here", not "licensing timed out", so neither a human nor an agent burns time on the outage hypothesis.
• Escalate explicitly. The recovery path is to rerun the launch once through Codex's approved outside-sandbox execution, where the same command succeeds.
• Keep the real failure reachable. Genuine entitlement problems still exist, so the probe distinguishes "context cannot resolve entitlements" from "this account has no entitlement", and each gets its own recovery.

#The new development matrix

The lasting change is not the probe, it's the mental model. The compatibility matrix used to be "my machine, CI, someone else's machine". It now has at least five rows:

• Interactive local execution
• Codex sandbox execution
• Codex approved host execution
• CI execution
• Another user or machine

Every one of these can share the same files while differing in identity, IPC, credentials, network access and permissions. The second and third rows are new, they sit on the same physical machine as the first, and tooling that has only ever been tested on row one will fail on them in ways the logs will misattribute.

≠Resource discovery does not imply resource usability

The generalisable debugging pattern, stated as rules:

1. Seeing a resource does not mean you can use it. A visible mutex, socket or file proves discovery, not capability.
2. Same username does not mean same security context. The sandboxed process and my desktop session were the same user and had very different effective permissions.
3. Same filesystem does not mean same host access. Sharing the project directory says nothing about WMI, keyrings or network policy.
4. Test the capabilities separately. Identity, synchronisation primitives, IPC, credentials and network are independent axes, and a sandbox can pass any subset.

The same trap is waiting anywhere a tool assumes ambient host capabilities: Docker sockets, SSH agents, credential keyrings, browser profiles, mobile simulators, code-signing services, the Unity and Unreal editors, local databases and development daemons. Each of these can be discoverable from an agent sandbox while being unusable from it, and each will produce its own genre of accurate-but-misleading log.

If you build tooling that agents will run, three habits follow directly: probe upstream capabilities before launching anything expensive, word your failures so a host-context problem cannot be mistaken for a project problem, and never automatically restart shared desktop services on the strength of a log line, because the "wedged" service may be serving your interactive session perfectly. Then test the sandboxed and approved-host paths as deliberately as you test CI, because they are environments now, whether or not they appear in your matrix.

Dead Air Works is an independent studio building SLIPFAULT, an arcade racing game for PC. More posts on the engineering as it ships.