bug: agent remains "running" after its runtime disappears

[aose-yuu]

What's broken

After a daemon worker crash and restart, one Codex agent remained listed as running even though its runtime no longer existed.

paseo inspect reported running, but paseo stop returned Agent not found. A normal archive then failed with AGENT_RUNNING. I had to use paseo archive --force to archive the agent.

If the runtime is gone, I would expect the stored state to be reconciled or paseo stop to behave as a no-op. In either case, a normal archive should not be blocked as if the agent were still running.

The daemon was healthy at this point, and other agents worked normally. Only this agent was stuck in the stale state.

Steps to reproduce

I cannot reproduce this on demand. This was the sequence I observed:

1. A Codex agent ran under /goal for several days and spawned provider-managed subagents.
2. The daemon worker reached its heap limit and restarted.
3. The persisted agent remained listed as running.
4. The agent later stopped producing output, but paseo inspect still reported running.
5. paseo stop returned Agent not found.
6. paseo archive returned AGENT_RUNNING.

CLI output, with the agent ID removed:

$ paseo inspect <agent-id> --json

{
  "Status": "running",
  "Archived": false,
  "Provider": "codex",
  "Model": "gpt-5.6-sol",
  "Mode": "full-access"
}

$ paseo stop <agent-id> --json

Warning: Failed to stop agent <agent-id>: Agent <agent-id> not found

{
  "stoppedCount": 0,
  "agentIds": []
}

$ paseo archive <agent-id> --json

{
  "error": {
    "code": "AGENT_RUNNING",
    "message": "Agent <agent-id> is currently running"
  }
}

paseo archive <agent-id> --force succeeded. After that, paseo inspect reported:

{
  "Status": "idle",
  "Archived": true
}

Where did this happen

Daemon, observed through the CLI and Desktop app.

Paseo version

0.2.5

OS version

macOS 15.7.3, arm64

Agent provider

Codex

Provider configuration

Codex CLI 0.144.1 with the OpenAI API.

• Model: gpt-5.6-sol
• Thinking: xhigh
• Mode: full-access

Logs

The cancellation request reached the daemon, but the runtime lookup failed:

{"level":30,"time":1785599570277,"daemonVersion":"0.2.5","msg":"Cancel request received for agent <agent-id>","agentId":"<agent-id>"}
{"level":50,"time":1785599570277,"daemonVersion":"0.2.5","msg":"Failed to cancel running agent on request for agent <agent-id>","agentId":"<agent-id>","error":"Agent <agent-id> not found"}

paseo archive --force then succeeded:

{"level":30,"time":1785599588532,"daemonVersion":"0.2.5","msg":"Archiving agent <agent-id>","agentId":"<agent-id>"}

Related issues

• bug: long-running Codex agents retain unbounded timeline history until daemon OOM #2300 tracks the long-running Codex history and OOM problem that happened before this.
• Desktop app stuck with persistent spinner/activity indicator after reinstall; daemon/CLI state inconsistent #2748 also reports inconsistent desktop and daemon state, but in that case the daemon was unreachable. Here, the daemon and other agents remained healthy.

[paseo-bot]

Keeping this open as a current P2 bug. On Paseo 0.2.5, the persisted lifecycle remained running after the worker restarted while runtime lookup returned Agent not found, which then blocked a normal archive with AGENT_RUNNING. The CLI output and daemon logs establish the inconsistent recovery state; archive --force is a workaround, so the impact is limited but actionable.

This is distinct from the triggering long-running-history OOM in #2300 and the unreachable-daemon state in #2748. I found no matching merged and released fix.