Best possible solution:

Keep the quarantine design, but make the bridge wrap or execute tools through a stable projected descriptor so name, description, and parameters are not re-read after validation, then add a regression test for a throwing description or one-shot parameters getter.

Do we have a high-confidence way to reproduce the issue?

Yes, source-reproducible: current main reads tool.parameters and tool.name directly while constructing the bridge, so a throwing accessor can abort startup before any quarantine path runs. I did not run the repro because this review was kept read-only.

Is this the best way to solve the issue?

No, not yet: quarantine-before-registration is the right layer, but the proposed implementation still re-reads descriptor accessors through wrapToolWithBeforeToolCallHook. The safer fix is to pass a stable projected tool shape into wrapping/spec creation or teach the wrapper to use already-read descriptor fields.

Full review comments:

• [P2] Avoid re-reading projected tool descriptors during wrapping — extensions/codex/src/app-server/dynamic-tools.ts:115
readCodexDynamicToolFields now catches a throwing description getter and keeps the tool with an empty description, but this line still passes the original object to wrapToolWithBeforeToolCallHook. That helper reads tool.name and spreads ...tool, so a descriptor getter that throws during wrapping still aborts createCodexDynamicToolBridge instead of quarantining the bad descriptor. Build the wrapped entry from the already-projected name/description/schema, or make the wrapper accept those projected fields, and cover a throwing description or one-shot parameters getter.
  Confidence: 0.88

Overall correctness: patch is incorrect
Overall confidence: 0.87

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against a595aba60e3b.

Label changes:

• add P2: This is a normal Codex dynamic-tool availability fix with limited blast radius, and the remaining blocker is a focused bridge correctness issue.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The external-contributor proof gate is not applicable to this member-authored maintainer PR; the body still includes focused test and direct tsx repro output as useful validation context.

Label justifications:

• P2: This is a normal Codex dynamic-tool availability fix with limited blast radius, and the remaining blocker is a focused bridge correctness issue.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The external-contributor proof gate is not applicable to this member-authored maintainer PR; the body still includes focused test and direct tsx repro output as useful validation context.

PR surface:

Source +83, Tests +29. Total +112 across 2 files.

Acceptance criteria:

• [P1] node scripts/run-vitest.mjs extensions/codex/src/app-server/dynamic-tools.test.ts --reporter=dot.
• [P1] node_modules/.bin/oxlint extensions/codex/src/app-server/dynamic-tools.ts extensions/codex/src/app-server/dynamic-tools.test.ts.
• [P1] git diff --check HEAD~1..HEAD.

What I checked:

• Repository policy read: Root and scoped extension policy were read; the root policy requires direct sibling Codex source inspection for Codex-runtime verdicts, and the extension policy keeps bundled plugin code on SDK-facing boundaries. (AGENTS.md:9, a595aba60e3b)
• Current-main failure path: Current main projects dynamic tools by reading tool.parameters and tool.name directly during createCodexDynamicToolBridge setup, so a throwing accessor aborts bridge construction before quarantine. (extensions/codex/src/app-server/dynamic-tools.ts:316, a595aba60e3b)
• Patch projection path: The PR adds readCodexDynamicToolFields and caches name, description, and inputSchema in ProjectedCodexDynamicTool before spec creation. (extensions/codex/src/app-server/dynamic-tools.ts:107, 88e0985fcf0d)
• Wrapper still re-reads descriptors: The before-tool-call wrapper reads tool.name and spreads the original tool object; descriptor getters can therefore still throw after projection and abort bridge setup. (src/agents/agent-tools.before-tool-call.ts:1093, a595aba60e3b)
• Codex dynamic-tool contract checked: Sibling Codex source shows DynamicToolSpec requires name, description, input_schema, and optional defer_loading, and app-server validation rejects invalid names/namespaces/schemas before thread start. (../codex/codex-rs/protocol/src/dynamic_tools.rs:8, f27bbbd49c0e)
• Feature history: Current dynamic-tools.ts and the before-tool-call wrapper are both blamed to the recent Codex app-server refactor commit, with earlier Codex app-server relocation history in d569803. (extensions/codex/src/app-server/dynamic-tools.ts:309, 2ea7c518a516)

Likely related people:

• vincentkoc: Current main blame for createCodexDynamicToolBridge, projectCodexDynamicTools, and wrapToolWithBeforeToolCallHook points to commit 2ea7c51, and this PR is also from the same area contributor. (role: recent area contributor; confidence: high; commits: 2ea7c518a516, 88e0985fcf0d; files: extensions/codex/src/app-server/dynamic-tools.ts, src/agents/agent-tools.before-tool-call.ts)
• steipete: Recent history on the Codex app-server path includes the app-server relocation and release-adjacent Codex changes, making this a useful routing fallback if the current branch needs broader Codex ownership review. (role: adjacent recent contributor; confidence: medium; commits: d5698038d71c, e93216080aa1; files: extensions/codex/src/app-server/dynamic-tools.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.