Repository navigation
fix(codex): launch-arg MCP servers survive the thread's t3-code server - #15839
lnieuwenhuis wants to merge 3 commits into
Conversation
Thread config is applied in the same layer as Codex -c launch flags, so a whole mcp_servers table replaced servers added via -c mcp_servers.<name>.*. Send the t3-code server under the dotted key mcp_servers.t3-code instead, and keep replay matching ignoring host-supplied MCP server config keys. Fixes pingdotgg#15828
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This is a small, localized Codex bug fix that preserves launch-argument MCP servers while still injecting the T3 server, with no schema, deployment, product-default, or static-analysis changes. The replay adjustment and updated unit expectation are correspondingly narrow. No code changes detected at You can add or adjust custom eligibility rules. Learn more. |
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Important Review skippedReview was skipped as selected files did not have any reviewable changes. ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (3)
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review. 📝 WalkthroughWalkthroughThe Codex thread runtime configuration now uses a dotted key for the ChangesCodex MCP configuration override
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~8 minutes Change: Bug fix · Severity of issue fixed: Medium Suggested reviewers: Merge Risk: ⚪ Minimal · up to The configuration change is mergeable; no actionable current-head risk was established. Architecture SummaryArchitecture risk: 🔵 Low · up to The change affects 2 systems. Changed systems: Architecture concerns Review detailsSystems and components
Before / after behavior
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Comment |
Fixes #15828
Codex thread config sent
mcp_servers: { "t3-code": ... }. Codex applies per-thread config in the same layer as the process's-cflags, so that single-segment key replaced the wholemcp_serverstable, and servers added through instance launch args (-c mcp_servers.extra.command=...) never started.The thread config now uses the dotted key
"mcp_servers.t3-code", the same wayCODEX_THREAD_CONFIGalready setstools.update_plan.enabled. It's built in one place,codexThreadRuntimeParams, which covers thread/start, thread/resume and thread/fork. The replay matcher ineffect-codex-app-serverdropsmcp_servers.*keys as well as the whole-table key, so recordings keep ignoring the per-machine URL and auth header.Verification
codex app-server(codex-cli 0.160.0, isolatedCODEX_HOME) launched with-c mcp_servers.extra.command="cat", then sentthread/startwith each config shape and collectedmcpServer/startupStatus/updatednotifications:mcp_servers: { "t3-code": ... }): onlyt3-codestarts"mcp_servers.t3-code": ...): botht3-codeandextrastartvp test runonCodexAdapterV2.test.ts(asserts the dotted key and that nomcp_serverstable is sent),CodexReplayFixtures.integration.test.ts, and the ThreadFork / OrchestratorReplayRecovery / ThreadMergeBack integration tests: all pass.effect-codex-app-servertypecheck clean.t3typecheck is clean apart from the duplicateOptionimport onmain, fixed separately in fix(server): the server starts again after a duplicate Option import #15837.Model/harness: Claude Opus 5.5 / Claude Code.