The bridge
Codex setup
Pagr drives Codex through its own local app-server. That is what lets a message land inside a turn that is already running, rather than waiting for it to finish.
Prerequisites#
npm i -g @openai/codexcodex logincodex --versioncodex login completes the login locally. Pagr never touches your OpenAI credentials — it does not read them, store them or transmit them.
As with Claude Code, codex has to be on the PATH that the launch agent captured. If pagr doctor says not found on PATH while your shell finds it fine, symlink it somewhere the agent can see or re-run pagr daemon install from a shell where which codex works.
How Pagr runs Codex#
The bridge starts one codex app-server process and talks to it over stdio JSON-RPC. Sessions are threads inside that process.
| Setting | Value |
|---|---|
| Approval policy | on-request — Codex asks, and the request is relayed to your phone |
| Sandbox | workspace-write normally, read-only for a review session |
| Steering | Supported — a follow-up can be injected into the active turn |
| Images | Supported, up to four per command |
The sandbox is re-asserted on every resume, so a read-only review session cannot quietly become writable when it is picked back up.
Checking the connection#
The bridge probes Codex on connect and reports install state, version and whether an account is signed in.
pagr statusAgents codex ✓ 0.9.4 (app-server, auth unknown)pagr status only does a local --version probe, so it always shows auth unknown. The dashboard shows the authoritative state, because that comes from the daemon. If Codex sessions fail immediately with an authentication error, the fix is almost always:
codex loginpagr daemon install # restart the daemon so it re-probespagr statusRestarts#
If the app-server exits unexpectedly, the bridge marks the affected sessions failed, resolves any approvals that were waiting on them, and restarts the process after a short delay. You are told what happened rather than left waiting on a session that is never coming back.