[saphid]

Problem

When a Codex agent starts a dev server, it never shows up in the thread's discovered servers ("see and stop the dev servers a thread started", #22542). The same server started by a Claude agent does.

#28604 gave Codex shells T3CODE_THREAD_ID, but port discovery only reads a listener's environment while it thinks an agent may be running. It learns that from PortDiscovery.trackAgent(), and only the Claude query runner calls it. After the startup scan, a Codex-only setup has no tracked agents, no pending scan, and no marked listeners. Every later scan skips the environment read, so the scanner never sees the thread id #28604 added. PortScanner.test.ts already spells this out: "With none marked, later scans stay idle."

Change

CodexAdapterV2.layerAppServerClientFactory.open now holds portDiscovery.trackAgent() in the app-server's scope (Effect.acquireRelease). It counts as a running agent for as long as that process lives, the same way the Claude runner counts its CLI process until it exits. The merged provider infrastructure layer already required PortDiscovery through Claude's layerQueryRunner, so no wiring changes.

Scope and approval

Very small, focused fix for an obvious bug, so no prior issue: #28604 says it lets a Codex agent's shell "attribute a dev server to it", and this is the missing half that makes the scanner look. It is one acquire/release in one adapter plus one test. The other providers (ACP, Antigravity, Cursor, OpenCode, Grok) don't set T3CODE_THREAD_ID at all. That is a separate parity question, left alone here.

Overlap search: local index and GitHub search for trackAgent, T3CODE_THREAD_ID, and Codex dev server/discovery. Closest: #28604 (merged, sets the env var only), #29669 (open, web sidebar setting, touches no server code), #27893 (merged, probe behaviour). None of them track Codex as an agent.

Verification

• New test in CodexAdapterV2.test.ts ("CodexAdapterV2 process exit"). It opens the real app-server client factory against a fake codex script with a mocked PortDiscovery, then checks the agent count is 1 while the session is open and 0 after its scope closes. On main it fails with AssertionError: expected +0 to equal 1.
• vp test run src/orchestration-v2/Adapters/CodexAdapterV2.test.ts: 134/134 pass (rerun after rebasing). ProviderInstanceRegistry.test.ts + ClaudeAgentSdkQueryRunner.test.ts: 32/32.
• vp run check:changed: format, lint, knip, graphql, typecheck (3 packages), tests all pass.
• Not checked: a live Codex turn starting a real dev server in a running T3 instance. The scanner side is already covered by the existing PortScanner agent-attribution tests.

Reviewed with sol-loop: 1 round with GPT-6.1 Sol on high. Sol verdict: approved.

Created with Claude Opus 5.5 in Claude Code (T3 Code).

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at b5a9aae

Macroscope's review found this PR approvable — Codex-started development servers now participate in existing thread-associated port discovery. The change reuses established discovery safeguards and scoped cleanup, with no material change to product defaults.

Notes:

• No code objects were reviewed. Approvability was decided on eligibility alone.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 55e2538
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: d0298850-3a6c-4474-95c9-c221d482ab7b

Commits

Reviewing files that changed from the base of the PR and between a0e988f and b5a9aae.

Files selected for processing: 1

• apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.test.ts

Limit details: You’ve used all 10 included reviews currently available.

Walkthrough

The Codex app-server client factory now uses PortDiscovery to track agents for the client scope. A test checks that tracking starts when the client opens and stops when the scope closes.

Changes: Codex agent tracking

Layer / File(s)	Summary
Scoped agent tracking apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts, apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.test.ts	The factory requires PortDiscovery and acquires agent tracking in the client scope. The test checks the tracked-agent count after opening the client and after the scope closes.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related PRs

• pingdotgg/t3code#22542: This PR introduces PortDiscovery.trackAgent(), which this change uses for the Codex app-server scope.

Suggested reviewers: juliusmarminge, maria-rcks

Merge Risk: Minimal · up to b5a9a

Codex server discovery is enabled for tracked sessions. No merge-blocking issue was established.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main fix: showing dev servers started by Codex agents under their thread.
Description check		The description includes the problem, change, scope rationale, approval context, detailed verification results, and the remaining live-environment check that was not performed.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Usage-based review receipt

• Mode: Continue automatically
• Reviewed files: 1
• Charged: $0.25
• View usage details

Note

This review was completed with usage-based billing: files reviewed beyond your plan's included limits are billed at $0.25/file. View usage-based billing.

CodeRabbit Verify

• Run CodeRabbit Verify to test the changes in this pull request.

[coderabbitai]

• Fix comments: Fix CodeRabbit comments on this PR

Dismissing prior approval to re-evaluate b5a9aae

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified unchanged head b5a9aae76d981abc4d6d62f566b7e68070e27aef on a linux boat vm using repository playwright, /usr/bin/google-chrome, and real codex gpt-6.1-sol turns through the local proxy.

• reproduced on github/main (57cd05904d) in a separate worktree. after the initial discovery scan, codex started a responding http server on port 43117 with the correct T3CODE_THREAD_ID. the actual client subscription returned servers: [] and the saved thread had no servers section.
• stopped main before starting the exact pr head. reused the app-created project and thread in isolated dev state. a new codex turn started the same server. the client received its pid, port, and matching agent.threadId; the ui showed Agent · MainThread.
• clicked the discovered row and saw the actual page in t3's browser panel. clicked the stop button, saw the row disappear, and independently confirmed the listener was gone and curl could no longer connect.
• sent another codex turn after stopping. it executed node successfully, printed CODEX_STILL_WORKS with the same thread id, and confirmed the port was closed.
• started the same server through the actual app terminal. it appeared as Terminal · MainThread with terminalId: term-1 and agent: null; stopping it through the ui worked. restarting through codex appeared as Agent again.
• blacksmith: focused codex adapter + port scanner tests passed (154 tests). vp run check:changed 55e25385619c7680dad0b0f34f5185187806c57a passed format, lint, knip, graphql, typechecks for 3 packages, and 135 tests. the worker needed pr history fetched before changed-file checks could resolve their merge base. existing ci reports 33 successful checks.

before, main with a responding codex-started listener:

after, same project, thread, server and port on the pr head:

opening the discovered server and stopping it through the ui:

short runtime transcript

Not verified

native ios/android clients, electron desktop, macos/windows process discovery, remote/relay/tunnel connections, other providers, and concurrent codex threads were not exercised on this linux web-client pass. video playback and seeking were checked in chrome; t3's rendered comment player was not available on this vm. no source changes were needed.