{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigseszrtfumw56od4ny26k3a4dkhavmci5godicfzmx4xsiftz5g4",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mlvbjfbmgkv2"
  },
  "path": "/t/clientresponseerror-tools/1380879#post_3",
  "publishedAt": "2026-05-15T10:53:30.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "github.com/openai/codex",
    "Simplify tool executor and registry plumbing (#22636)",
    "jif-oai",
    "+827\n-1005",
    "…"
  ],
  "textContent": "I know there have been many recent changes and commits in Codex related to `tools`. I am not sure whether the API and Codex are connected in this case, but if they are, this example of a commit may shed some light on the issue:\n\ngithub.com/openai/codex\n\n####  Simplify tool executor and registry plumbing (#22636)\n\ncommitted 09:47AM - 15 May 26 UTC\n\n\n\n          jif-oai\n        \n\n\n+827\n-1005\n\n\n## Why The tool runtime path still had a typed output associated type on `ToolE…xecutor`, plus a core-only `RegisteredTool` adapter and extension-only executor aliases. That made every new shared tool runtime carry extra adapter plumbing before it could participate in core dispatch, extension tools, hook payloads, telemetry, and model-visible spec generation. This PR moves output erasure to the shared executor boundary so core and extension tools can use the same execution contract directly. ## What Changed - Changed `codex_tools::ToolExecutor` to return `Box<dyn ToolOutput>` instead of an associated `Output` type. - Removed the extension-specific `ExtensionToolExecutor` / `ExtensionToolOutput` aliases and exposed `ToolExecutor<ToolCall>` plus `ToolOutput` through `codex-extension-api`. - Reworked core tool registration around `CoreToolRuntime` and `ToolRegistry::from_tools`, removing the extra `RegisteredTool` / `ToolRegistryBuilder` layer. - Consolidated model-visible spec planning and registry construction in `core/src/tools/spec_plan.rs`, including deferred tool search and code-mode-only filtering. - Added `ToolOutput` helpers for post-tool-use hook ids and inputs so MCP, unified exec, extension, and other boxed outputs preserve the same hook payload behavior. - Updated core handlers, memories tools, and the related registry/spec/router tests to use the simplified contract. ## Test Coverage - Updated coverage for tool spec planning, registry lookup, deferred tool search registration, extension tool routing, post-tool-use hook payloads, dispatch tracing, guardian output extraction, and memories extension tool execution.\n\nA similar pattern happened a few days ago when users were reporting MCP problems around the same time there were Codex commits related to MCP.\n\nAgain, this is only a guess, but there are at least a few facts that seem to correlate.",
  "title": "ClientResponseError/Tools"
}