codex-preflight
On-demand general Codex runtime preflight for network/TLS/writable-roots/tool/provider readiness using `scripts/codex-preflight.sh`.
Codex preflight
When to use
- You see sandbox-ish errors like
PermissionError: [Errno 1] Operation not permitted,seccomp, or unexpected “Permission denied” when paths look writable. - You need to know if network is disabled in the tool sandbox before attempting auth, installs,
git push, etc. - You want an explicit environment readiness snapshot for helper CLIs like
read-pdf,pdf-to-markdown,llm, orwbg-auth. - You want a compact provider/auth readiness view for CLIs like
gh,gcloud,gws,llm,aws,az, oroci.
Workflow
- Run the preflight helper:
scripts/codex-preflight.sh
Compatibility note: scripts/codex-sandbox-preflight.sh still exists as a shim,
but scripts/codex-preflight.sh is the canonical script name.
- If you’re in a normal shell and want structured output:
scripts/codex-preflight.sh --json
- If you’re in a normal shell and want to see what happens when network is enabled inside the sandbox:
scripts/codex-preflight.sh --with-network
- Summarize results (don’t paste the full output unless asked):
- Tool sandbox network:
socket()allowed vs blocked (and DNS if allowed). - TLS / CA trust: whether Python HTTPS can complete a TLS handshake, and whether CA-related env vars, Node CA env vars, proxy env vars, or local WBG CA bundle preparation look relevant.
- Runtime environment: Python interpreter path/version and venv status, uv version, Node toolchain versions, and whether the session appears to be in WSL, Windows, or a container.
- Repo state: current git branch and a concise staged/unstaged/untracked summary when inside a git worktree.
- Workflow tools: whether
tk,read-pdf,pdf-to-markdown,llm, andwbg-authare available, plus a concisetkqueue summary when applicable. - Provider auth readiness: whether
codex,gh,gcloud,gws,llm,aws,az, andocilook ready, missing, partial, or unsupported. - Writable roots: whether
~/.config/wbg-authis writable inside the sandbox. - Config drift: whether
~/.codex/config.tomlis symlinked to dotfiles or has diverged.
Interpretation cheatsheet
INFO- socket() syscall blocked:- Tool sandbox has network disabled (expected in many sandboxed sessions).
- Avoid network-dependent commands/tools inside the sandbox.
- To allow sandbox network, start Codex with
-c sandbox_workspace_write.network_access=true(still sandboxed, but with egress).
WARN missing_writable_root=$HOME/.config/wbg-auth(or similar) / sandbox write fails for~/.config/wbg-auth:wbg-authwill crash on startup due to log file creation.- Fix by adding
~/.config/wbg-authtosandbox_workspace_write.writable_rootsin~/.codex/config.toml.
WARN- python TLS handshake ... failed certificate verification:- Network reachability exists, but Python HTTPS trust is broken.
- On the WBG MITM network, refresh the local CA install with
bin/wbg-ca-helper install-wsl-trust. - For Python tools that use
requests/certifi, exportingREQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crtandSSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crtcan be necessary even when basic socket and DNS checks pass.
Notes / pitfalls
- Running this from inside an already-restricted tool sandbox cannot “prove” that enabling network would work; outer seccomp will still block
socket(). Use--with-networkfrom a normal shell for that. - On corporate MITM networks, basic socket and DNS success does not guarantee Python HTTPS success; read the TLS / CA section before assuming “network is OK”.
- This helper must never print secrets; it only checks tool presence, config linkage, writability, DNS, and certificate-trust readiness.
- Prefer the stable command
codex-preflightwhen it is onPATH; the old sandbox-named entrypoint is compatibility-only.