[juliusmarminge]

makeCodexAppServerProtocolLogger was bound to the thread that opened the shared Codex app-server, so every thread on that app-server logged into the opener's events file. The logger now routes each decoded frame to its own T3 thread. thread/start, resume (including rollback's resume) and fork requests carry the T3 thread id in per-thread config (shell_environment_policy.set.T3CODE_THREAD_ID). The matching response's result.thread.id records the native-to-T3 mapping. Later requests and notifications resolve through params.threadId or params.thread.id. Responses inherit their request's thread, keyed by who sent the request plus the JSON-RPC id. A sub-agent thread/started maps the child to its parent through source.subAgent.thread_spawn.parent_thread_id. Frames with no thread (initialize, initialized, config/read, configWarning) go to the global provider log (events._global.log); the issue left this to a maintainer, so it is worth a look in review. The logger's threadId input was removed. Reproduced before the fix on the VM's preview server: thread B got no file and its prompt was in thread A's file. Verified after the fix on the worktree dev server with two Codex threads (gpt-6-luna, gpt-6.1-sol): each got its own events file with its own prompt and model (27 records each), and the 11 thread-less frames went to the global log. No new regex or parser. Thread lookup is a fixed-depth property read, constant per frame. The pending-request map only grows with requests that never get a response, and is released with the app-server session. Note: the first repro attempt used the t3 CLI without --base-dir and created a scratch project and two threads on the VM's live server; I removed them with t3 project remove --force.

Fixes #35952

Reproduction on main

Commit 97cfc07 (origin/main). In a fresh worktree: vp i, then T3CODE_DEV_SEED=0 vp run dev (fresh database). Created a scratch git repo and ran node src/bin.ts project add on it. Started two Codex threads a few seconds apart with node src/bin.ts thread start --provider codex --model gpt-6-luna --title "Thread A" <proj> "Reply with the word alpha only." (thread mcp:152aabb1-...) and the same with --model gpt-6.1-sol (thread mcp:dd58e8b6-...). Both turns completed, and both provider threads show provider_session_id provider-session:provider-instance:codex:shared. Result: .t3/userdata/logs/provider/ held a single file, events.mcp-152aabb1-50e9-494e-b380-d82cef52e320.log, with 65 codex.app-server protocol records. Mapping native Codex thread ids through orchestration_v2_projection_provider_threads in the worktree's own dev database: 01a1d32c-d763-... = thread A (25 records), 01a1d32c-d9b9-... = thread B (25 records, including B's gpt-6.1-sol model). Thread B got no events file at all.

Evidence

Start an isolated real dev server with T3CODE_DEV_SEED=0 on each commit. Add a scratch git project, start Codex Thread A with gpt-6-luna, then Thread B with gpt-6.1-sol, both prompted to reply with alpha only. Both turns completed and shared one app-server. Inspect provider logs against native thread IDs in the dev database.

Before	After
0c4b1d8f27	b83a4417b4
65 records in A's file; 25 native-ID references each for A and B.	27 records per thread file; 25 native-ID references exclusively to its owner. 11 unscoped records go to the global log.

These are rendered captures of actual server-output analysis, not UI screenshots. Before record inventory, after record inventory, capture script, reproduction commands.

Not shown:

• Resume, fork, and server-initiated request routing were not exercised; this proof covers the reported two-new-thread reproduction.

Tests

vp test run src/orchestration-v2/Adapters/CodexAdapterV2.test.ts: 161 passed (extended the existing native protocol logging test with two threads on one logger, a turn response and a thread-less response). vp run check:changed: format, lint, knip, typecheck (3 packages) and tests (2 files, 163) all pass. Manual: T3CODE_DEV_SEED=0 vp run dev plus t3 thread start --base-dir <worktree>/.t3 for two Codex threads; each got its own events..log.

Not in this change

• Sub-agent child threads have their own T3 child thread ids but their Codex protocol records are logged under the parent T3 thread; giving them their own files would need the adapter's subagent mapping in the logger.
• The app-server is still spawned with the opening thread's id passed to AgentScope.wrap (makeCodexAppServerSpawnCommand threadId); unrelated to logging, not changed.

Who did the work

• Written by Claude Opus 5.5, in Claude Code
• Reviewed by GPT-6.1 Sol, in Codex, and by Claude Opus 5.5, each on its own
• Proof captured by GPT-6.1 Sol and checked by Claude Opus 5.5

Run by the t3code factory in T3 Code.

[macroscopeapp]

🟡 Medium Adapters/CodexAdapterV2.ts:1569

When concurrent requests for different threads use IDs 1 and "1", both map to server:1, so the later mapping overwrites the earlier one; responses are then logged under the wrong thread or in the global log. Include typeof id in requestKey so numeric and string JSON-RPC IDs remain distinct.

Suggested change

	const requestKey =
	typeof id === "string" || typeof id === "number"
	? `${isRequest === (direction === "outgoing") ? "client" : "server"}:${id}`
	: undefined;
	const requestKey =
	typeof id === "string" || typeof id === "number"
	? `${isRequest === (direction === "outgoing") ? "client" : "server"}:${typeof id}:${id}`
	: undefined;

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts around lines 1569-1572:

When concurrent requests for different threads use IDs `1` and `"1"`, both map to `server:1`, so the later mapping overwrites the earlier one; responses are then logged under the wrong thread or in the global log. Include `typeof id` in `requestKey` so numeric and string JSON-RPC IDs remain distinct.

[macroscopeapp]

🟠 High Adapters/CodexAdapterV2.ts:1587

Legacy execCommandApproval and applyPatchApproval requests are logged globally instead of under their mapped thread, and their responses are also logged globally. This lookup omits params.conversationId, so include it as a fallback for nativeThreadId to save the request mapping.

Suggested change

	readCodexProtocolPath(params, "threadId") ?? readCodexProtocolPath(params, "thread", "id");
	let threadId =
	const nativeThreadId =
	readCodexProtocolPath(params, "threadId") ??
	readCodexProtocolPath(params, "thread", "id") ??
	readCodexProtocolPath(params, "conversationId");

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts around lines 1587-1588:

Legacy `execCommandApproval` and `applyPatchApproval` requests are logged globally instead of under their mapped thread, and their responses are also logged globally. This lookup omits `params.conversationId`, so include it as a fallback for `nativeThreadId` to save the request mapping.

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	21.5 KiB	21.5 KiB	0 B (0.0%)	24.4 KiB	✅
Codex	Live turn messages	1	1	0 (0.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.9 KiB	21.9 KiB	0 B (0.0%)	24.4 KiB	✅
Claude	Live turn messages	1	1	0 (0.0%)	8	✅

Other scenarios

All 64 scenario measurements match main.

All 64 scenario measurements

Provider	Scenario	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	short turn resume	WebSocket decoded	10.5 KiB	10.5 KiB	0 B (0.0%)	12.7 KiB	✅
Codex	short turn resume	WebSocket messages	2	2	0 (0.0%)	2	✅
Codex	long turn running, cold open	HTTP decoded	281.7 KiB	281.7 KiB	0 B (0.0%)	302.7 KiB	✅
Codex	long turn running, cold open	rows	75	75	0 (0.0%)	75	✅
Codex	long turn running, history page	HTTP decoded	92.4 KiB	92.4 KiB	0 B (0.0%)	107.4 KiB	✅
Codex	long turn running, history page	rows	75	75	0 (0.0%)	75	✅
Codex	long turn finished, cold open	HTTP decoded	381.5 KiB	381.5 KiB	0 B (0.0%)	410.2 KiB	✅
Codex	long turn finished, cold open	rows	151	151	0 (0.0%)	151	✅
Codex	long turn finished, socket cold open	WebSocket decoded	381.6 KiB	381.6 KiB	0 B (0.0%)	410.2 KiB	✅
Codex	long turn finished, socket cold open	WebSocket messages	2	2	0 (0.0%)	2	✅
Codex	long turn finished, socket cold open	rows	151	151	0 (0.0%)	151	✅
Codex	long turn finished, work page	HTTP decoded	186.2 KiB	186.2 KiB	0 B (0.0%)	200.2 KiB	✅
Codex	long turn finished, work page	rows	150	150	0 (0.0%)	150	✅
Codex	idle thread resume	WebSocket decoded	65 B	65 B	0 B (0.0%)	200 B	✅
Codex	idle thread resume	WebSocket messages	1	1	0 (0.0%)	1	✅
Codex	fleet shell snapshot	HTTP decoded	42.4 KiB	42.4 KiB	0 B (0.0%)	53.7 KiB	✅
Codex	fleet shell snapshot	rows	27	27	0 (0.0%)	27	✅
Codex	fleet shell subscribe	WebSocket decoded	65 B	65 B	0 B (0.0%)	200 B	✅
Codex	fleet shell subscribe	WebSocket messages	1	1	0 (0.0%)	1	✅
Codex	fleet shell resume check	HTTP decoded	18 B	18 B	0 B (0.0%)	100 B	✅
Codex	fleet shell resume check	rows	0	0	0	0	✅
Codex	stale shell reload	HTTP decoded	42.4 KiB	42.4 KiB	0 B (0.0%)	53.7 KiB	✅
Codex	stale shell reload	rows	27	27	0 (0.0%)	27	✅
Codex	stale shell resume	WebSocket decoded	140 B	140 B	0 B (0.0%)	400 B	✅
Codex	stale shell resume	WebSocket messages	2	2	0 (0.0%)	2	✅
Codex	stale todo list cold open	HTTP decoded	72.4 KiB	72.4 KiB	0 B (0.0%)	83.0 KiB	✅
Codex	stale todo list cold open	rows	75	75	0 (0.0%)	75	✅
Codex	stale todo list cold open	nodes	2	2	0 (0.0%)	4	✅
Codex	stale todo list cold open	subagents	2	2	0 (0.0%)	4	✅
Codex	stale todo list cold open	plans	1	1	0 (0.0%)	2	✅
Codex	stale todo list cold open	providerTurns	1	1	0 (0.0%)	2	✅
Codex	stale todo list cold open	checkpoints	1	1	0 (0.0%)	2	✅
Claude	short turn resume	WebSocket decoded	10.6 KiB	10.6 KiB	0 B (0.0%)	12.7 KiB	✅
Claude	short turn resume	WebSocket messages	2	2	0 (0.0%)	2	✅
Claude	long turn running, cold open	HTTP decoded	283.3 KiB	283.3 KiB	0 B (0.0%)	302.7 KiB	✅
Claude	long turn running, cold open	rows	75	75	0 (0.0%)	75	✅
Claude	long turn running, history page	HTTP decoded	93.4 KiB	93.4 KiB	0 B (0.0%)	107.4 KiB	✅
Claude	long turn running, history page	rows	75	75	0 (0.0%)	75	✅
Claude	long turn finished, cold open	HTTP decoded	384.2 KiB	384.2 KiB	0 B (0.0%)	410.2 KiB	✅
Claude	long turn finished, cold open	rows	151	151	0 (0.0%)	151	✅
Claude	long turn finished, socket cold open	WebSocket decoded	384.3 KiB	384.3 KiB	0 B (0.0%)	410.2 KiB	✅
Claude	long turn finished, socket cold open	WebSocket messages	2	2	0 (0.0%)	2	✅
Claude	long turn finished, socket cold open	rows	151	151	0 (0.0%)	151	✅
Claude	long turn finished, work page	HTTP decoded	188.1 KiB	188.1 KiB	0 B (0.0%)	200.2 KiB	✅
Claude	long turn finished, work page	rows	150	150	0 (0.0%)	150	✅
Claude	idle thread resume	WebSocket decoded	66 B	66 B	0 B (0.0%)	200 B	✅
Claude	idle thread resume	WebSocket messages	1	1	0 (0.0%)	1	✅
Claude	fleet shell snapshot	HTTP decoded	43.0 KiB	43.0 KiB	0 B (0.0%)	53.7 KiB	✅
Claude	fleet shell snapshot	rows	27	27	0 (0.0%)	27	✅
Claude	fleet shell subscribe	WebSocket decoded	66 B	66 B	0 B (0.0%)	200 B	✅
Claude	fleet shell subscribe	WebSocket messages	1	1	0 (0.0%)	1	✅
Claude	fleet shell resume check	HTTP decoded	18 B	18 B	0 B (0.0%)	100 B	✅
Claude	fleet shell resume check	rows	0	0	0	0	✅
Claude	stale shell reload	HTTP decoded	43.0 KiB	43.0 KiB	0 B (0.0%)	53.7 KiB	✅
Claude	stale shell reload	rows	27	27	0 (0.0%)	27	✅
Claude	stale shell resume	WebSocket decoded	140 B	140 B	0 B (0.0%)	400 B	✅
Claude	stale shell resume	WebSocket messages	2	2	0 (0.0%)	2	✅
Claude	stale todo list cold open	HTTP decoded	73.4 KiB	73.4 KiB	0 B (0.0%)	83.0 KiB	✅
Claude	stale todo list cold open	rows	75	75	0 (0.0%)	75	✅
Claude	stale todo list cold open	nodes	2	2	0 (0.0%)	4	✅
Claude	stale todo list cold open	subagents	2	2	0 (0.0%)	4	✅
Claude	stale todo list cold open	plans	1	1	0 (0.0%)	2	✅
Claude	stale todo list cold open	providerTurns	1	1	0 (0.0%)	2	✅
Claude	stale todo list cold open	checkpoints	1	1	0 (0.0%)	2	✅

Baseline: b7a224c · PR result: b83a441 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — Codex protocol records are routed to their associated thread logs, with unassociated frames going to the global log. Existing logging safeguards remain unchanged; the reported routing defects are covered by the separate correctness gate.

Needs human approval because:

• 2 blocking correctness issues found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}