This session gave me a useful reminder: Codex configuration is not one switch.
It is three separate gates. And each gate fails in its own way.
We saw that while trying to run a session-content-capture workflow into pm_bot. On paper, it looked simple. The draft existed. The import path existed. The local app was running.
And still, the workflow would not complete.
The reason was not that the system was generally broken. The reason was that the workflow had to cross three boundaries, and each boundary had its own control.
The first gate was environment loading.
The variables we needed, `PM_BOT_ROOT` and `PM_BOT_APP_URL`, were already defined in `.envrc`. But that did not mean the commands could see them. Codex was running non-interactive shell commands, so the runtime environment did not automatically inherit what looked correctly configured on the surface. Until `direnv` was loaded inside the same command, it appeared as if the contract itself was wrong.
The second gate was writable roots.
The workflow needed to write session draft artifacts into `pm_bot/store/session-content-drafts`, which sits outside the current repo. A small typo in the writable-root configuration meant Codex could write where we were testing, but not where the real app expected the files to go. So the logic was fine, but the filesystem boundary was still closed.
The third gate was network access.
Once the files could be written and the app was running locally, the final import still failed because the sandbox was not allowed to make the localhost HTTP request. That part is easy to miss. In this setup, localhost is still network. A workflow can succeed at file creation and still fail on the final POST because `127.0.0.1` is blocked.
What made the lesson clear is that the failures arrived in sequence. First the variables looked missing. Then the importer path looked suspect. Then the write target was blocked. Then the local HTTP call failed.
That is not randomness. That is the system telling you, one boundary at a time, which gate is still closed.
The practical takeaway is simple. When Codex has to work outside the current repo, debug three checks separately. Confirm the environment variables are visible inside the exact command being run. Confirm the destination path is actually inside writable roots. Confirm localhost, or any other required network target, is explicitly allowed.
Once you start reading sandbox failures that way, they become easier to reason about. You are no longer asking, "Why is the workflow broken?" You are asking a smaller and more useful question: is this an environment problem, a filesystem problem, or a network problem?
That turns a vague failure into a short checklist. And in practice, that is usually the difference between flailing and fixing.
-----------
If you find this content useful, please share it with this link: [https://patrickmichael.co.za/subscribe](https://patrickmichael.co.za/subscribe)