Recorded demo
Remote Codex Control: approval replay
Remote Codex Control (RCC) is a human-approval layer for autonomous coding agents: an operator approves, steers or denies each tool action from a private Telegram chat while the code stays on their own machine. This page replays a real session from the project's demo script.
The daemon reports its health and its link to the coding agent.
Operator: /status
RCC: RCC Status Daemon: alive Codex Transport: connected App Server Compatibility: compatible Thread List Health: ok Thread List Last Success: <time> Last Event: <time> Event Age: <age> Freshness Threshold: 90s Recent Event Healthy: yes Freshness State: healthy_quiet Active Threads: 0 Remote Mode: focused_thread_stream + background_alerts Remote Approval Mode: app_server_then_manual_desktop Desktop Approval Fallback: disabled (desktop-only approvals must be handled on the Mac) Telegram Commands: installed Sleep Prevention: not_expected Codex prevent_idle_sleep: unknown Sleep Prevention Mismatch: no
Only allowlisted project folders are listed.
Operator: /projects
RCC: Projects (1) 1. demo-app | ~/demo-app
The operator starts an agent thread in a project from the phone.
Operator: /new 1 Demo thread
RCC: Running Project: demo-app Thread: Demo thread Turn: <id-1> Thread created Project: demo-app Codex ID: <id-2> Path: ~/demo-app Turn started: <id-1> Use /say <change> while running.
The agent asks for permission. RCC sends an approval card with the project, thread and action.
Operator: /approval_demo
RCC: Demo approval triggered for Demo thread Approval ID: <id-3> Approval needed Category: unknown Risk: unknown Why Codex wants this: RCC could not classify this approval with high confidence. What will happen: Demo approval card: confirm remote approval path. Project: demo-app Thread: Demo thread Turn: <id-1> cwd: <tmp>/demo-app Source: demo Approval ID: <id-3> Age: just now Decision hint: Deny or inspect details unless you recognize the action. Actions: /approve <id-3> | /deny <id-3> | /approval <id-3>
Pending approvals are listed with their age.
Operator: /approvals
RCC: Approvals Pending actionable: 1 demo-app / Demo thread 1. <id-3> turn: <id-1> | action: other | risk: unknown age: <age> | expiry n/a Demo approval card: confirm remote approval path. actions: /approve <id-3> | /deny <id-3> | /interrupt <id-2> Superseded/expired approvals are hidden here and rejected if tapped from old cards.
The operator approves. The decision goes back to the agent.
Operator: /approve <id-3>
RCC: Approval resolved Project: demo-app Thread: Demo thread Decision: approved Source: app-server After approval Project: demo-app Thread: Demo thread Decision: approved Status: running Action: Demo approval card: confirm remote approval path. Tip: /last for full context. Approved request <id-3>
A repeated tap is recognised and does not act twice.
Operator: /approve <id-3>
RCC: Callback already processed: approve:<id-3>
A request that is already resolved cannot be changed.
Operator: /deny <id-3>
RCC: Request <id-3> already approved
An unknown approval ID is rejected.
Operator: /approve does-not-exist
RCC: Command failed: Unknown approval does-not-exist
What this shows
- Approval routing with project and thread context.
- Idempotent callbacks: a repeated tap is recognised and does not act twice.
- Stale or unknown approvals rejected.
This is a recorded transcript from npm run demo in the repository. It runs the real daemon against mock Codex and Telegram clients, so it needs no bot token and no Codex install. IDs and times are shown as placeholders.