app-server: no way to list running sessions or steer one, and nothing marks liveness outside the daemon

Summary

There is no supported way to list which Codex sessions are currently running, or to send input to one mid-turn, even though the app-server protocol already models both.

Per the schema emitted by codex app-server generate-json-schema, thread/list returns a per-thread status (notLoaded | idle | active | systemError), and turn/steer / turn/interrupt act on an in-flight turn. That surface is only reachable through the app-server daemon, and nothing about a running session is persisted outside it. For anyone running several agents in parallel terminals, the capability is effectively unavailable.

Environment

• codex-cli 0.146.0, installed via npm
• Linux

What I can verify

A running session is indistinguishable from a finished one in the persisted store.

I have a TUI session running right now. Its thread row in ~/.codex/state_5.sqlite:

id            019fc100-eebe-7ec0-83a9-9d3b4acedd13
cwd           /home/me/project
git_branch    feat/some-branch
source        cli
thread_source user
updated_at    1785652655
archived      0

A thread from a codex exec run that finished an hour earlier has the same shape, differing only in source and updated_at. The threads table has no status, no pid, and no liveness column of any kind, so there is no offline way to tell the two apart:

id, rollout_path, created_at, updated_at, source, model_provider, cwd, title,
sandbox_policy, approval_mode, tokens_used, has_user_event, archived, archived_at,
git_sha, git_branch, git_origin_url, cli_version, first_user_message,
agent_nickname, agent_role, memory_mode, model, reasoning_effort, agent_path,
created_at_ms, updated_at_ms, thread_source, preview, recency_at, recency_at_ms,
history_mode, name, is_pinned

Everything else useful for a fleet view is already persisted there: cwd, git_branch, git_origin_url, source, name. Liveness is the only missing piece.

The daemon is not startable on an npm install.

$ codex app-server daemon start
Error: managed standalone Codex install not found at ~/.codex/packages/standalone/current/codex
This command requires the standalone install managed by the Codex installer, [...]

So for npm users the protocol surface above is not reachable at all without switching install methods.

What I could not verify

Because of the above, I could not test whether a TUI session started in a separate terminal registers with a running daemon and shows up in thread/list as active. If it does, the gap is narrower than it appears and is mostly about the npm install path and discoverability. If it does not, then status only ever describes threads the daemon itself launched, and terminal sessions are permanently invisible to it.

I would appreciate a maintainer confirming which of those is the case, since it determines whether this is a docs issue or a feature gap.

Why it matters

Running several agents in parallel terminals, there is no way to check whether two of them are working in the same repository or on the same branch before they collide, and no way to redirect one mid-turn without switching to its terminal. External reconstruction requires matching live PIDs to /proc/<pid>/cwd and then guessing which rollout belongs to which process by cwd and mtime, which is ambiguous as soon as two sessions share a directory.

Proposal

Have the TUI register its thread with the app-server daemon when one is running, so the existing thread/list status, turn/steer, and turn/interrupt apply to terminal sessions unchanged.

Failing that, persisting a liveness record (pid + thread id + status) alongside the existing thread metadata would let any client build the listing without a daemon at all.

Related

• #36363
• #36416
• #31074