Troubleshooting a failed agent session
A command that drives an agent (run, resume, artifact new, artifact decide, review-code, review-compliance) can fail because the agent's session did. This page is for the moment it prints ✗ <provider> session failed (<kind>): … and you want to know whether to retry, resume or fix something.
Read the failure line
A run whose phase lost the network prints:
- The kind in parentheses says what happened:
network,provider-error,max-turns,killed,unknown, or a limit (rate-limit,usage-limit). - The text after it is the provider's own message, not phax's.
session:is the provider's session id, when it reported one.See …names the two files to read.agent-error.logstarts with afailure:header (the cause), then the command that ran and the provider's stderr. The transcript (output.jsonl) sits beside it.- A
networkfailure ends with the command to run again once you are back online. Everyphax resumeit names carries--yes: without it,phax resumeonly previews.
Example: the network went away
You run phax artifact decide while your DNS is down. The agent retries ten times, gives up, and phax prints the failure with the decide session's own folder and its retry:
The command exits 14.
If records are on with transcripts and an in-repo destination, phax also asks gh whether the repository is public, and that needs the network too. The record is refused, and the refusal is printed after the failure it follows:
Read it as a consequence of the outage, not a second problem. Once the network is back, run the retry command the failure printed. The record is written by the retry. Setting acknowledgedUnknownVisibility is not the fix: phax only suggests it when gh failed for a reason a retry cannot cure.
For a run, the failed phase's own record can be refused the same way (phase record refused, following the failed session: …). A run that lost the network pauses instead of failing: phax ls lists it as rate_limited, the state a limit leaves too, but there is no reset time to wait for, so you can resume it as soon as the network is back. phax resume <run> --yes starts a new provider session in the same worktree; the work the phase had done there stays.
Codex does not end its session when the network goes: it prints Reconnecting... and keeps waiting for the network. If a Codex phase sits there, interrupt phax (Ctrl-C), then resume the run once the network is back.
Exit codes
A failure after a retry
When the next session starts in the same folder (a resume of the phase, the retried handoff), phax first archives the failure the earlier session left there, so agent-error.log only ever describes the latest failure:
agent-error.logbecomesagent-error.failed-NN.log, numbered from01in that folder.- The transcript the new session is about to write takes the same number before its extension:
output.jsonlbecomesoutput.failed-NN.jsonl(a Vibe turn'soutput.vibe-export/becomesoutput.failed-NN.vibe-export/). The archived log'stranscript:line names the new name. - A transcript the new session does not write (an earlier closing turn's
closing-turn-01.jsonl, say) stays where it is, and the archived log still names it.
A phase's record carries agent-error.failed-NN.log as it carries agent-error.log, but never an archived transcript: it is another session's.
When the same failure keeps coming back
- A
networkfailure that persists with a working connection usually means a proxy or firewall in front of the provider. The provider's message names the error it got (ENOTFOUND,ECONNREFUSED,All connection attempts failed), not always the host. - A
provider-errorthat quotes an authentication message needs you to log in to the provider's own CLI again. - Wording phax does not recognise as a connection problem reads as
provider-error(exit 5), even when the cause is the network. Ifagent-error.logshows a connection error under exit 5, the retry is still the right move; please report the wording.