# ClientResponseError/Tools **URL:** \ **Category:** GPT builders\ **Tags:** tools\ **Created:** [May 13, 2026, 7:47pm UTC](https://community.openai.com/t/clientresponseerror-tools/1380879 "2026-05-13T19:47:27Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Nicholas\_Walker](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/nicholas_walker/32/697205_2.png) [@Nicholas\_Walker](https://community.openai.com/u/Nicholas_Walker)\ **Post date:** [May 13, 2026, 7:47pm UTC](https://community.openai.com/t/clientresponseerror-tools/1380879/1 "2026-05-13T19:47:27Z")
I have been getting frequent ClientResponseError coming back from Tool requests from a custom GPT the last two days. My APIs are alive and operational. The problem seems to come and go. Anybody else experiencing this? ---
**Author:** ![OpenAI\_Support](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/openai_support/32/561845_2.png) [@OpenAI\_Support](https://community.openai.com/u/OpenAI_Support)\ **Post date:** [May 14, 2026, 1:59pm UTC](https://community.openai.com/t/clientresponseerror-tools/1380879/2 "2026-05-14T13:59:50Z")
Thanks for flagging this - that definitely sounds frustrating, especially if everything on your end looks healthy. Would you mind creating a support ticket for this? That’ll help our team take a closer look at what’s happening under the hood and investigate any intermittent issues like the one you’re describing. Once the ticket is created, please share the case ID here so I can take a look at it internally and help move things along. Appreciate you reporting it! - Smith ---
**Author:** ![EricGT](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/ericgt/32/20571_2.png) [@EricGT](https://community.openai.com/u/EricGT)\ **Post date:** [May 15, 2026, 10:53am UTC](https://community.openai.com/t/clientresponseerror-tools/1380879/3 "2026-05-15T10:53:30Z")
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: > > > \## 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\\` > instead of an associated \`Output\` type. > \- Removed the extension-specific \`ExtensionToolExecutor\` / > \`ExtensionToolOutput\` aliases and exposed \`ToolExecutor\\` 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. A similar pattern happened a few days ago when users were reporting MCP problems around the same time there were Codex commits related to MCP. Again, this is only a guess, but there are at least a few facts that seem to correlate. ---
**Author:** ![Ecira](https://avatars.discourse-cdn.com/v4/letter/e/e9c0ed/32.png) [@Ecira](https://community.openai.com/u/Ecira)\ **Post date:** [May 15, 2026, 12:07pm UTC](https://community.openai.com/t/clientresponseerror-tools/1380879/4 "2026-05-15T12:07:13Z")
Hi. If anyone can find a solution to this problem please let us know here. The issue is very frustrating since we can’t do anything about it. And as mentioned it is flaky. I managed to work only once after several tries and no more luck after that. Thanks to those who is dedicatedly working on this. But please update us for any potential solutions or workaround that is available. Right now no call is working. Custom GPT lost a lot of viability for this issue. ---
**Author:** ![Sunn\_e](https://avatars.discourse-cdn.com/v4/letter/s/b5ac83/32.png) [@Sunn\_e](https://community.openai.com/u/Sunn_e)\ **Post date:** [May 27, 2026, 5:57pm UTC](https://community.openai.com/t/clientresponseerror-tools/1380879/5 "2026-05-27T17:57:53Z")
---
**Author:** ![OpenAI\_Support](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/openai_support/32/561845_2.png) [@OpenAI\_Support](https://community.openai.com/u/OpenAI_Support)\ **Post date:** [May 27, 2026, 6:47pm UTC](https://community.openai.com/t/clientresponseerror-tools/1380879/6 "2026-05-27T18:47:31Z")
The issue should be resolved. Let us know if that's not the case.