Best possible solution:

Land the bridge-level quarantine after maintainer review and any desired broad/live Codex proof, keeping malformed plugin tools out of Codex specs while healthy sibling tools remain available.

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

Yes from source: current main directly reads Codex dynamic-tool descriptor fields during projection/spec creation, so poisoned getters can throw before bridge creation completes. I did not execute tests in this read-only review.

Is this the best way to solve the issue?

Yes. The patch fixes the bridge boundary by caching validated descriptor data, quarantining unreadable/wrapping failures, and preventing Codex from seeing tools that are unavailable to execute; relying only on build-stage filtering would leave direct bridge callers less protected.

AGENTS.md: found and applied where relevant.

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

Label justifications:

• P2: This is a normal-priority Codex dynamic-tool runtime hardening with focused tests and limited blast radius.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🦞 diamond lobster.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The external-contributor proof gate is not applied because this is a maintainer-member PR; the body reports focused tests/lint/autoreview and explicitly notes no live Codex turn ran.

PR surface:

Source +133, Tests +110. Total +243 across 2 files.

What I checked:

• Repository policy read and applied: Full root AGENTS.md and scoped extensions/AGENTS.md were read; the Codex dependency-source gate and extension boundary review rules affected this review. (AGENTS.md:1, 5c5391836b1e)
• Current-main failure path is source-reproducible: Current main projects tool schemas by directly reading tool.name/tool.parameters and later reads tool.name/tool.description while creating specs, so descriptor getters can throw before the bridge returns. (extensions/codex/src/app-server/dynamic-tools.ts:110, 5c5391836b1e)
• PR bridge hardening: The PR projects readable descriptors into cached entry fields, wraps projected tools behind a quarantine boundary, filters registered specs against quarantined available tool names, and builds specs from cached descriptor data. (extensions/codex/src/app-server/dynamic-tools.ts:102, 26135a1bc9d0)
• Regression coverage: The added test covers unreadable name, unreadable parameters, empty name, wrapping-time execute getter failure, healthy sibling preservation, and registered spec filtering. (extensions/codex/src/app-server/dynamic-tools.test.ts:374, 26135a1bc9d0)
• Runtime callers checked: The main Codex app-server run path creates the bridge with current-turn tools plus durable registeredTools, and the side-question path creates the same bridge for side dynamic tools. (extensions/codex/src/app-server/run-attempt.ts:595, 5c5391836b1e)
• Codex dependency contract checked: Upstream Codex app-server protocol accepts DynamicToolSpec with name, description, input_schema, namespace, and defer_loading, and exposes dynamic tool execution through item/tool/call. (../codex/codex-rs/app-server-protocol/src/protocol/v2/thread.rs:42, e648ec771f1f)

Likely related people:

• vincentkoc: Authored the prior Codex dynamic-tool schema quarantine and diagnostics commits and also authored this PR's focused follow-up in the same bridge/tests. (role: feature owner and recent area contributor; confidence: high; commits: d7d037b46f32, da5fe990d8b3, 26135a1bc9d0; files: extensions/codex/src/app-server/dynamic-tools.ts, extensions/codex/src/app-server/dynamic-tools.test.ts, src/agents/tool-schema-projection.ts)
• steipete: Current local blame points at a recent broad refactor touching the Codex app-server bridge files, and GitHub history shows a recent docs pass for the Codex dynamic-tool bridge. (role: recent area contributor; confidence: medium; commits: ce015cef5775, 7139f473332f; files: extensions/codex/src/app-server/dynamic-tools.ts, extensions/codex/src/app-server/run-attempt.ts, extensions/codex/src/app-server/side-question.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.