app-server: Replay pending item requests on `thread/resume` by euroelessar · Pull Request #12560 · openai/codex

euroelessar · 2026-02-23T09:06:11Z

Replay pending client requests after thread/resume and emit resolved notifications when those requests clear so approval/input UI state stays in sync after reconnects and across subscribed clients.

Affected RPCs:

item/commandExecution/requestApproval
item/fileChange/requestApproval
item/tool/requestUserInput

Motivation:

Resumed clients need to see pending approval/input requests that were already outstanding before the reconnect.
Clients also need an explicit signal when a pending request resolves or is cleared so stale UI can be removed on turn start, completion, or interruption.

Implementation notes:

Use pending client requests from OutgoingMessageSender in order to replay them after thread/resume attaches the connection, using original request ids.
Emit item/commandExecution/approvalResolved, item/fileChange/approvalResolved, and item/tool/requestUserInputResolved when pending requests are answered or cleared by lifecycle cleanup.
Update the app-server protocol schema, generated TypeScript bindings, and README docs for the replay/resolution flow.

High-level test plan:

Added automated coverage for replaying pending command execution and file change approval requests on thread/resume.
Added automated coverage for resolved notifications in command approval, file change approval, request_user_input, turn start, and turn interrupt flows.
Verified schema/docs updates in the relevant protocol and app-server tests.

Manual testing:

Tested reconnect/resume with multiple connections.
Confirmed state stayed in sync between connections.

Replay pending client requests after `thread/resume` and emit resolved notifications when those requests clear so approval/input UI state stays in sync after reconnects and across subscribed clients. Affected RPCs: - `item/commandExecution/requestApproval` - `item/fileChange/requestApproval` - `item/tool/requestUserInput` Motivation: - Resumed clients need to see pending approval/input requests that were already outstanding before the reconnect. - Clients also need an explicit signal when a pending request resolves or is cleared so stale UI can be removed on turn start, completion, or interruption. Implementation notes: - Track pending client requests in `ThreadState` and replay them after `thread/resume` attaches the connection. - Reuse the original JSON-RPC request id for replays and resend prerequisite notifications like `item/started` for pending file change approvals. - Emit `item/commandExecution/approvalResolved`, `item/fileChange/approvalResolved`, and `item/tool/requestUserInputResolved` when pending requests are answered or cleared by lifecycle cleanup. - Update the app-server protocol schema, generated TypeScript bindings, and README docs for the replay/resolution flow. High-level test plan: - Added automated coverage for replaying pending command execution and file change approval requests on `thread/resume`. - Added automated coverage for resolved notifications in command approval, file change approval, request_user_input, turn start, and turn interrupt flows. - Verified schema/docs updates in the relevant protocol and app-server tests. Manual testing: - Not run.

owenlin0 · 2026-02-26T16:29:53Z

codex-rs/app-server-protocol/src/protocol/common.rs

+    CommandExecutionApprovalResolved => "item/commandExecution/approvalResolved" (v2::CommandExecutionApprovalResolvedNotification),
    FileChangeOutputDelta => "item/fileChange/outputDelta" (v2::FileChangeOutputDeltaNotification),
+    FileChangeApprovalResolved => "item/fileChange/approvalResolved" (v2::FileChangeApprovalResolvedNotification),
+    ToolRequestUserInputResolved => "item/tool/requestUserInputResolved" (v2::ToolRequestUserInputResolvedNotification),


ooc, why do we need these? can't clients resolve things based on receiving item/completed?

i.e. server will send:

item/started notification for file change / command execution / etc.

item/commandExecution/requestApproval request

a client responds

item/completed notification

we don't have item/started/item/completed events for user input at all, as there is no corresponding item, iiuc

in case of file changes, they are synthesized, but not always? e.g. I don't think we never emit item/completed in cases like turn interruption and such (which could be a bug); also harness is allowed to send multiple requests for the same item, so there is no one-to-one mapping between requests & items for file changes approvals in particular, it's many-to-one

due to points above it's just easier (from protocol perspective & client-side consumption) and more consistent to have dedicated events

as a side note, it should be fine to merge these events into just single one if you prefer, I've only split them to mirror having multiple independent rpcs

ah ok, we might want to add an item for representing the user input tool call. I had to do that recently for dynamic tool calls: #12732

but you're right, we're going to move to a world soon where there are multiple approvals for a CommandExecution so we can't rely on item/completed for that either. proceed :)

naming nit: since our requests are like item/commandExecution/requestApproval should we name these notifications item/commandExecution/requestApproval/resolved?

basically just appending /resolved to the corresponding server method name

codex-rs/app-server/src/outgoing_message.rs

maxj-oai · 2026-02-26T17:11:12Z

codex-rs/app-server/src/outgoing_message.rs

+        notifications_before_request: &[ServerNotification],
+    ) -> bool {
+        // Hold the callback map lock until the replay is queued so an already-resolved
+        // request cannot be replayed to a resumed client.


stresses me out - prefer to make this not needed for correctness, or use try_send
I don't fully understand what race this prevents - even if we send an already-resolved request event that should be ok right? since the client will observe the resolution as well right after (due to ordering guarantee provided by the thread listener task)

yeah, I agree, we already serialize resolution properly so should be fine, simplified

codex-rs/app-server/src/thread_state.rs

…ume-requests

maxj-oai

awesome, ty!

codex-rs/app-server/src/bespoke_event_handling.rs

codex-rs/app-server/src/thread_state.rs

owenlin0

trying my best to review but it's getting quite hard to follow :(

owenlin0 · 2026-02-27T00:56:38Z

codex-rs/app-server/src/outgoing_message.rs

+        connection_ids: Option<&[ConnectionId]>,
        request: ServerRequestPayload,
        thread_id: Option<ThreadId>,
+        tracked_request: bool,


what makes a request "tracked" or not?

it's essentially a workaround to avoid closing rpcs for dynamic tool & v1, as I wanted to maintain status quo in their behavior
alternatively could check for the type (but that feels more hackier), or spend more type drilling into them to make sure they are not broken by the change

bit the bullet and gone through all the remaining server->client requests to add proper handling of abortion into them, so no need for tracked requests anymore

owenlin0 · 2026-02-27T00:57:08Z

codex-rs/app-server/src/outgoing_message.rs

            .await
    }

+    pub(crate) async fn send_request_with_server_request(


what's the difference between this and send_request?

this one was returning a request id as well, merged them into one & updated all callsites for simplicity

codex-rs/app-server/src/outgoing_message.rs

codex-rs/app-server/tests/suite/v2/request_user_input.rs

codex-rs/app-server/src/codex_message_processor.rs

owenlin0 · 2026-02-27T01:15:39Z

codex-rs/app-server/src/codex_message_processor.rs

+    outgoing.send_server_notification(notification).await;
+}
+
+pub(crate) async fn abort_pending_client_requests(outgoing: &ThreadScopedOutgoingMessageSender) {


can this be a method on ThreadScopedOutgoingMessageSender?

yep, updated

owenlin0

nice, much cleaner!!

owenlin0 · 2026-02-27T18:48:03Z

codex-rs/app-server/src/bespoke_event_handling.rs

    } = event;
    match msg {
        EventMsg::TurnStarted(_) => {
+            outgoing.abort_pending_client_requests().await;


nit: maybe worth a comment on why we need this, still not super clear to me 🤷

owenlin0 · 2026-02-27T18:51:02Z

codex-rs/app-server/src/thread_state.rs

@@ -29,13 +31,24 @@ pub(crate) struct PendingThreadResumeRequest {
 }

 pub(crate) enum ThreadListenerCommand {


prob worth a comment on what this (and the variants) are used for

owenlin0 · 2026-02-27T18:51:59Z

codex-rs/app-server/src/thread_state.rs

 #[derive(Default, Clone)]
 pub(crate) struct TurnSummary {
-    pub(crate) file_change_started: HashSet<String>,
+    pub(crate) file_change_started: HashMap<String, Vec<FileUpdateChange>>,


curious, why did we need to change it to a hashmap here?

owenlin0 · 2026-02-27T19:01:46Z

codex-rs/app-server/src/outgoing_message.rs

+                    code: INTERNAL_ERROR_CODE,
+                    message: "client request resolved because the turn state was changed"
+                        .to_string(),
+                    data: Some(serde_json::json!({ "reason": "turnTransition" })),


can import the const you defined: TURN_TRANSITION_PENDING_REQUEST_ERROR_REASON

…ume-requests

etraut-openai added the oai PRs contributed by OpenAI employees label Feb 23, 2026

euroelessar force-pushed the ruslan/thread-resume-requests branch from d0a1dc7 to 593d7d9 Compare February 26, 2026 02:06

euroelessar force-pushed the ruslan/thread-resume-requests branch from 593d7d9 to 60ee51e Compare February 26, 2026 05:32

clippy

033ea2d

github-actions bot mentioned this pull request Feb 26, 2026

📊 AI CLI 工具社区动态日报 2026-02-26 duanyytop/agents-radar#14

Open

owenlin0 reviewed Feb 26, 2026

View reviewed changes

maxj-oai reviewed Feb 26, 2026

View reviewed changes

euroelessar added 2 commits February 26, 2026 09:54

Merge branch 'main' of github.com:openai/codex into ruslan/thread-res…

86e35c9

…ume-requests

cr

6e22dd7

maxj-oai approved these changes Feb 26, 2026

View reviewed changes

owenlin0 reviewed Feb 26, 2026

View reviewed changes

codex-rs/app-server/src/bespoke_event_handling.rs Outdated Show resolved Hide resolved

codex-rs/app-server/src/thread_state.rs Outdated Show resolved Hide resolved

cr

8aa8b02

github-actions bot mentioned this pull request Feb 27, 2026

📊 AI CLI 工具社区动态日报 2026-02-27 duanyytop/agents-radar#20

Open

maybe fix windows test?

2a5afcd

owenlin0 reviewed Feb 27, 2026

View reviewed changes

euroelessar added 5 commits February 26, 2026 21:29

cr v2

0ef57de

rm useless method

1972490

rm more "codex/event/task_complete"

1890f30

style, be consistent re client vs server request terminology

05b716d

fix test?

784d95c

owenlin0 approved these changes Feb 27, 2026

View reviewed changes

euroelessar added 3 commits February 27, 2026 11:49

cr + only single event

bd3d111

typos

0d93755

Merge branch 'main' of github.com:openai/codex into ruslan/thread-res…

926dd10

…ume-requests

euroelessar merged commit 69d7a45 into main Feb 27, 2026
85 of 95 checks passed

euroelessar deleted the ruslan/thread-resume-requests branch February 27, 2026 20:46

github-actions bot locked and limited conversation to collaborators Feb 27, 2026

		@@ -29,13 +31,24 @@ pub(crate) struct PendingThreadResumeRequest {
		}

		pub(crate) enum ThreadListenerCommand {

Conversation

euroelessar commented Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

owenlin0 Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

maxj-oai left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

owenlin0 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

owenlin0 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

euroelessar commented Feb 23, 2026 •

edited

Loading

owenlin0 Feb 26, 2026 •

edited

Loading