I'm running three agents headless in Docker on a VPS (buzz 0.5.0 binaries from the Linux .deb, buzz-acp spawning claude-agent-acp 0.63.0, hosted relay). Two of them use Claude Code with a subscription login. Both died about a day after I signed them in, and I had no way of knowing.
Bumble was signed in around 01:10 UTC on 29 July. First failure 06:31 on 30 July — roughly 29 hours later. Fizz was signed in ~01:24 on the 29th, first failure 20:14 on the 30th, so about 43 hours. Since then every single mention fails:
ERROR pool::prompt: session_prompt error: Agent reported error (code -32000): Authentication required
WARN buzz_acp: agent_returned (application error — pipe intact) agent=0 outcome="error"
Running claude auth status inside the container confirms it:
{"loggedIn": false, "authMethod": "none", "apiProvider": "firstParty"}The credentials went stale and there's no browser in the container to complete a refresh, which I understand. That part is my problem for running it headless.
The part I think is a bug is that nothing shows this. The container is Up, the harness stays connected to the relay, and presence set to online never changes. In the client the agent looks completely normal. Fizz sat dead for hours while showing online, and I only found out because I happened to check the logs of a third agent that was working.
Presence seems to reflect the harness's websocket, not whether the agent can actually do anything. When session_prompt returns Authentication required on every turn, the agent isn't online in any sense the user cares about.
A few things would each have saved me the confusion, in rough order of how useful they'd have been:
- Presence going away or changing after N consecutive
outcome="error" turns
- The harness posting something into the channel when it can't authenticate, so the failure appears where you're already looking
- A non-zero exit or an unhealthy signal so Docker/systemd notices, rather than staying up in a broken state
Worth noting the third agent, running goose against an API key instead of a subscription login, has zero auth errors over the same period. So this is specific to credential types that expire and need an interactive refresh.
Possibly related: #2265 — same shape (Claude agent silently stops working), different cause.
I'm running three agents headless in Docker on a VPS (buzz 0.5.0 binaries from the Linux .deb,
buzz-acpspawningclaude-agent-acp0.63.0, hosted relay). Two of them use Claude Code with a subscription login. Both died about a day after I signed them in, and I had no way of knowing.Bumble was signed in around 01:10 UTC on 29 July. First failure 06:31 on 30 July — roughly 29 hours later. Fizz was signed in ~01:24 on the 29th, first failure 20:14 on the 30th, so about 43 hours. Since then every single mention fails:
Running
claude auth statusinside the container confirms it:{"loggedIn": false, "authMethod": "none", "apiProvider": "firstParty"}The credentials went stale and there's no browser in the container to complete a refresh, which I understand. That part is my problem for running it headless.
The part I think is a bug is that nothing shows this. The container is
Up, the harness stays connected to the relay, andpresence set to onlinenever changes. In the client the agent looks completely normal. Fizz sat dead for hours while showing online, and I only found out because I happened to check the logs of a third agent that was working.Presence seems to reflect the harness's websocket, not whether the agent can actually do anything. When
session_promptreturnsAuthentication requiredon every turn, the agent isn't online in any sense the user cares about.A few things would each have saved me the confusion, in rough order of how useful they'd have been:
outcome="error"turnsWorth noting the third agent, running
gooseagainst an API key instead of a subscription login, has zero auth errors over the same period. So this is specific to credential types that expire and need an interactive refresh.Possibly related: #2265 — same shape (Claude agent silently stops working), different cause.