codex

app-server service tier plumbing (plus some cleanup) (#13334 )

followup to https://github.com/openai/codex/pull/13212 to expose fast
tier controls to app server
(majority of this PR is generated schema jsons - actual code is +69 /
-35 and +24 tests )

- add service tier fields to the app-server protocol surfaces used by
thread lifecycle, turn start, config, and session configured events
- thread service tier through the app-server message processor and core
thread config snapshots
- allow runtime config overrides to carry service tier for app-server
callers

cleanup:
- Removing useless "legacy" code supporting "standard" - we moved to
None | "fast", so "standard" is not needed.

pash-openai · 2026-03-03 02:35:09 -08:00

07e532dcb9

app-server: Add ephemeral field to Thread object (#13084 )

Currently there is no alternative way to know that thread is ephemeral,
only client which did create it has the knowledge.

Ruslan Nigmatullin · 2026-02-27 17:42:25 -08:00

8c1e3f3e64

notify: include client in legacy hook payload (#12968 )

## Why

The `notify` hook payload did not identify which Codex client started
the turn. That meant downstream notification hooks could not distinguish
between completions coming from the TUI and completions coming from
app-server clients such as VS Code or Xcode. Now that the Codex App
provides its own desktop notifications, it would be nice to be able to
filter those out.

This change adds that context without changing the existing payload
shape for callers that do not know the client name, and keeps the new
end-to-end test cross-platform.

## What changed

- added an optional top-level `client` field to the legacy `notify` JSON
payload
- threaded that value through `core` and `hooks`; the internal session
and turn state now carries it as `app_server_client_name`
- set the field to `codex-tui` for TUI turns
- captured `initialize.clientInfo.name` in the app server and applied it
to subsequent turns before dispatching hooks
- replaced the notify integration test hook with a `python3` script so
the test does not rely on Unix shell permissions or `bash`
- documented the new field in `docs/config.md`

## Testing

- `cargo test -p codex-hooks`
- `cargo test -p codex-tui`
- `cargo test -p codex-app-server
suite::v2::initialize::turn_start_notify_payload_includes_initialize_client_name
-- --exact --nocapture`
- `cargo test -p codex-core` (`src/lib.rs` passed; `core/tests/all.rs`
still has unrelated existing failures in this environment)

## Docs

The public config reference on `developers.openai.com/codex` should
mention that the legacy `notify` payload may include a top-level
`client` field. The TUI reports `codex-tui`, and the app server reports
`initialize.clientInfo.name` when it is available.

Michael Bolin · 2026-02-26 22:27:34 -08:00

e6cd75a684

feat: sub-agent injection (#12152 )

This PR adds parent-thread sub-agent completion notifications and change
the prompt of the model to prevent if from being confused

jif-oai · 2026-02-19 11:32:10 +00:00

2daa3fd44f

fix: file watcher (#12105 )

The issue was that the file_watcher never unsubscribe a file watch. All
of them leave in the owning of the ThreadManager. As a result, for each
newly created thread we create a new file watcher but this one never get
deleted even if we close the thread. On Unix system, a file watcher uses
an `inotify` and after some time we end up having consumed all of them.

This PR adds a mechanism to unsubscribe a file watcher when a thread is
dropped

jif-oai · 2026-02-18 18:28:34 +00:00

f675bf9334

feat: phase 2 usage (#12121 )

jif-oai · 2026-02-18 11:33:55 +00:00

2293ab0e21

[apps] Add thread_id param to optionally load thread config for apps feature check. (#11279 )

- [x] Add thread_id param to optionally load thread config for apps
feature check

Matthew Zeng · 2026-02-09 23:10:26 -08:00

005e040f97

feat(app-server): turn/steer API (#10821 )

This PR adds a dedicated `turn/steer` API for appending user input to an
in-flight turn.

## Motivation
Currently, steering in the app is implemented by just calling
`turn/start` while a turn is running. This has some really weird quirks:
- Client gets back a new `turn.id`, even though streamed
events/approvals remained tied to the original active turn ID.
- All the various turn-level override params on `turn/start` do not
apply to the "steer", and would only apply to the next real turn.
- There can also be a race condition where the client thinks the turn is
active but the server has already completed it, so there might be bugs
if the client has baked in some client-specific behavior thinking it's a
steer when in fact the server kicked off a new turn. This is
particularly possible when running a client against a remote app-server.

Having a dedicated `turn/steer` API eliminates all those quirks.

`turn/steer` behavior:
- Requires an active turn on threadId. Returns a JSON-RPC error if there
is no active turn.
- If expectedTurnId is provided, it must match the active turn (more
useful when connecting to a remote app-server).
- Does not emit `turn/started`.
- Does not accept turn overrides (`cwd`, `model`, `sandbox`, etc.) or
`outputSchema` to accurately reflect that these are not applied when
steering.

Owen Lin · 2026-02-06 00:35:04 +00:00

0d8b2b74c4

feat: sqlite 1 (#10004 )

Add a `.sqlite` database to be used to store rollout metatdata (and
later logs)
This PR is phase 1:
* Add the database and the required infrastructure
* Add a backfill of the database
* Persist the newly created rollout both in files and in the DB
* When we need to get metadata or a rollout, consider the `JSONL` as the
source of truth but compare the results with the DB and show any errors

jif-oai · 2026-01-28 15:29:14 +01:00

3878c3dc7c

feat: ephemeral threads (#9765 )

Add ephemeral threads capabilities. Only exposed through the
`app-server` v2

The idea is to disable the rollout recorder for those threads.

jif-oai · 2026-01-24 14:57:40 +00:00

83775f4df1

feat: add wait tool implementation for collab (#9088 )

Add implementation for the `wait` tool.

For this we consider all status different from `PendingInit` and
`Running` as terminal. The `wait` tool call will return either after a
given timeout or when the tool reaches a non-terminal status.

A few points to note:
* The usage of a channel is preferred to prevent some races (just
looping on `get_status()` could "miss" a terminal status)
* The order of operations is very important, we need to first subscribe
and then check the last known status to prevent race conditions
* If the channel gets dropped, we return an error on purpose

jif-oai · 2026-01-12 12:16:24 +00:00

623707ab58

chore: unify conversation with thread name (#8830 )

Done and verified by Codex + refactor feature of RustRover

jif-oai · 2026-01-07 17:04:53 +00:00

116059c3a0

12 Commits