Skip to content

Experimental Codex run backend via app-server JSON-RPC (daemon thread + turn) #4

Description

@devgony

Context

Recent Codex CLIs (v0.149+; verified locally on 0.153.0-alpha.5) ship an experimental app-server daemon: codex app-server daemon start|stop|..., codex agents (browse agent sessions on the shared daemon), codex queue --thread <uuid> --message, WebSocket/unix-socket remote control with bearer auth, and protocol schema generators (codex app-server generate-json-schema).

However codex exec — what rein run uses for the Codex backend — is still a standalone foreground process:

So rein currently backgrounds codex exec itself and owns the log/status files (see the DEFAULT_CODEX_RUN_CMD comment in src/commands/exec.rs).

Proposal (experimental, opt-in)

Add a third Codex launch mode that talks JSON-RPC to the local app-server daemon instead of spawning codex exec:

  1. Ensure the daemon is up (codex app-server daemon start, or connect to the control socket at $CODEX_HOME/app-server-control/app-server-control.sock).
  2. Create a thread with the task worktree as cwd, run a turn with the rein item/task prompt ($REIN_PROMPT).
  3. Record the thread id in the task's RunRecord (same shape as today — session, agent: "codex", item), stream turn events into <store>/runs/*.log so L / rein logs keep working, and reuse the existing post-run rein todo completeness check.
  4. a (attach) keeps resuming by thread id; sessions launched this way should also show up in codex agents.

Config: rein.runAgent = codex-app-server (or a rein.codexDaemon = true toggle). Keep codex exec as the default.

Why not now

Trigger to pick this up

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions