History

Owen Lin f1653dd4d3 feat(app-server, core): return threads by created_at or updated_at (#9247 ) Add support for returning threads by either `created_at` OR `updated_at` descending. Previously core always returned threads ordered by `created_at`. This PR: - updates core to be able to list threads by `updated_at` OR `created_at` descending based on what the caller wants - also update `thread/list` in app-server to expose this (default to `created_at` if not specified) All existing codepaths (app-server, TUI) still default to `created_at`, so no behavior change is expected with this PR. Implementation To sort by `updated_at` is a bit nontrivial (whereas `created_at` is easy due to the way we structure the folders and filenames on disk, which are all based on `created_at`). The most naive way to do this without introducing a cache file or sqlite DB (which we have to implement/maintain) is to scan files in reverse `created_at` order on disk, and look at the file's mtime (last modified timestamp according to the filesystem) until we reach `MAX_SCAN_FILES` (currently set to 10,000). Then, we can return the most recent N threads. Based on some quick and dirty benchmarking on my machine with ~1000 rollout files, calling `thread/list` with limit 50, the `updated_at` path is slower as expected due to all the I/O: - updated-at: average 103.10 ms - created-at: average 41.10 ms Those absolute numbers aren't a big deal IMO, but we can certainly optimize this in a followup if needed by introducing more state stored on disk. Caveat There's also a limitation in that any files older than `MAX_SCAN_FILES` will be excluded, which means if a user continues a REALLY old thread, it's possible to not be included. In practice that should not be too big of an issue. If a user makes... - 1000 rollouts/day → threads older than 10 days won't show up - 100 rollouts/day → ~100 days If this becomes a problem for some reason, even more motivation to implement an updated_at cache.		2026-01-16 20:58:55 +00:00
..
src	feat(app-server, core): return threads by created_at or updated_at (#9247 )	2026-01-16 20:58:55 +00:00
Cargo.toml	chore: add small debug client (#8894 )	2026-01-08 13:40:14 +00:00
README.md	chore: add small debug client (#8894 )	2026-01-08 13:40:14 +00:00

README.md

WARNING: this code is mainly generated by Codex and should not be used in production

codex-debug-client

A tiny interactive client for codex app-server (protocol v2 only). It prints all JSON-RPC lines from the server and lets you send new turns as you type.

Usage

Start the app-server client (it will spawn codex app-server itself):

cargo run -p codex-debug-client -- \
  --codex-bin codex \
  --approval-policy on-request

You can resume a specific thread:

cargo run -p codex-debug-client -- --thread-id thr_123

CLI flags

--codex-bin <path>: path to the codex binary (default: codex).
-c, --config key=value: pass through --config overrides to codex.
--thread-id <id>: resume a thread instead of starting a new one.
--approval-policy <policy>: untrusted, on-failure, on-request, never.
--auto-approve: auto-approve command/file-change approvals (default: decline).
--final-only: only show completed assistant messages and tool items.
--model <name>: optional model override for thread start/resume.
--model-provider <name>: optional provider override.
--cwd <path>: optional working directory override.

Interactive commands

Type a line to send it as a new turn. Commands are prefixed with ::

:help show help
:new start a new thread
:resume <thread-id> resume a thread
:use <thread-id> switch active thread without resuming
:refresh-thread list available threads
:quit exit

The prompt shows the active thread id. Client messages (help, errors, approvals) print to stderr; raw server JSON prints to stdout so you can pipe/record it unless --final-only is set.

Notes

The client performs the required initialize/initialized handshake.
It prints every server notification and response line as it arrives.
Approvals for item/commandExecution/requestApproval and item/fileChange/requestApproval are auto-responded to with decline unless --auto-approve is set.