[Bug]: Codex protocol events are logged under whichever thread opened the app-server, not the thread they belong to #35952

Before submitting#

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area#

apps/server

Steps to reproduce#

1. Start the server with no Codex session open.
2. Send a message in Codex thread A. This starts the Codex app-server.
3. While that app-server is still open, send a message in a second Codex thread B. Starting two Codex delegates from one parent works too.
4. Open logs/provider/ under the T3 home's userdata directory.

Expected behavior#

events.<thread B>.log holds thread B's codex.app-server protocol records, the way each Claude thread's file holds its own.

Actual behavior#

Thread B's records are appended to events.<thread A>.log, and thread B's own file gets none of them.

layerAppServerClientFactory builds the protocol logger once, when the app-server opens, and passes it the thread that asked for the open:

const protocolLogger = makeCodexAppServerProtocolLogger({
  nativeEventLogger,
  threadId: input.threadId,
  providerSessionId: input.providerSessionId,
});

makeCodexAppServerProtocolLogger then passes that same input.threadId to nativeEventLogger.write for every event (apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts, lines 1547 and 1668 at 97cfc07759). The app-server is shared: every Codex thread on an instance uses the provider session provider-session:provider-instance:codex:shared. So the thread id fixed at open names the file for every thread that uses the app-server afterwards. Claude opens one CLI per thread, so its logger does not have this problem.

Numbers from one install, where I mapped each record's native Codex thread id to its T3 thread through orchestration_v2_projection_provider_threads. Codex subagent threads are counted with the thread that started them.

• 13 of 27 log files with Codex records hold records from more than one thread.
• One file from 2026-11-12 holds records from 11 delegated threads. Another from 2026-11-10 holds 5.
• On 0.1.10-nightly.20261112.4606, a file named for one top-level thread took 467 records that belong to a second top-level thread within six minutes.

Impact#

Minor bug or occasional failure

This affects diagnostics only. Reading or sharing one thread's provider log to debug it shows another thread's protocol traffic, and the records for the thread being debugged are in a file named for a different thread.

Version or commit#

0.1.10-nightly.20261112.4606, and main @ 97cfc07759

Environment#

macOS 27.2, desktop app with the service-managed server, Codex provider.

Possible fix#

Pick the file per event, not per app-server. The adapter has to map a notification's native threadId to its T3 thread to route it, so the logger could use that mapping and fall back to the opening thread for records that carry no thread id, such as initialize.

A question for a maintainer: should records with no thread id go to the opening thread's file as they do now, or to a file named for the provider session?

Related work#

• #29744 and #29770 fixed delegated threads from one parent sharing a single log file. That was a file-name collision, and it is fixed. The files from 2026-11-10 and 2026-11-12 above were written after that fix, with distinct names.