Claude Code returns 400 on a custom API? Check the Artifact schema
Identify the Claude Code Artifact input_schema regression on third-party endpoints, check the client version, and separate it from other HTTP 400 errors.
Ofox 
If Claude Code started failing on every turn after an update and the error mentions an invalid regular expression in an Artifact tool input schema, check the client version before replacing your key or model. The user report #92969 in the official repository reports a regression in versions 2.1.265 and 2.1.266: a schema pattern containing Unicode property escapes was rejected by strict validators.
This is a specific historical compatibility failure. It is not an explanation for every HTTP 400, and it should not be presented as an unfixed problem in all current clients. The official Claude Code changelog records the third-party endpoint fix in 2.1.268.
Match the error before applying the fix
Three observations make this issue worth checking: the failures began with the affected client update, the request uses a third-party Anthropic-compatible endpoint, and the error points to the Artifact tool’s schema or a pattern that is “not a regex.” The exact response wording can differ between validators.
A schema rejection occurs before the model can answer the user’s task. Changing the prompt from a complex coding request to a greeting may therefore leave the error unchanged. That does not prove the model is broken; the invalid part can be in a tool definition included with the request.
| Error clue | Likely investigation |
|---|---|
| Artifact input_schema and invalid pattern | Check the affected Claude Code versions and fixed release |
| Missing tool_result after tool_use | Inspect conversation/tool-result ordering |
| Invalid thinking signature | Check preserved thinking blocks and provider compatibility |
| 401 or 403 | Inspect authentication and authorization separately |
| 429 | Inspect limits rather than schema syntax |
The table is a routing aid, not an automatic diagnosis. Save the full redacted error and compare its field path with the original issue. Do not remove unrelated safeguards or rewrite every tool schema because one request was rejected.
Check the version actually running
Start with the command’s reported version:
claude --versionIf you use a terminal, an IDE and a background worker, check each execution environment. They may use different installations. After updating through your normal installation method, restart the relevant client or worker and verify the version again.
Version 2.1.268 is the historical release containing this fix, not a recommendation to downgrade a newer supported installation. Use your organization’s supported current version. If an environment is intentionally pinned to an affected release, treat the pin as part of the diagnosis and follow the normal update process.
The update needs to reach the client building the request. Updating an unrelated local terminal does not change a separately deployed worker. Record which process sent the failing request and which one sent the successful retest.
Retest one request before restarting a long task
Keep the same provider and model for the initial retest. Use a harmless task and record whether the original schema rejection still appears. A success after updating supports the diagnosis for that configuration; it does not certify every provider feature.
Then test the relevant tool workflow, because a plain text response alone does not exercise the same tool sequence. Preserve the client version, provider route, request time, redacted error and any request identifier. If the provider still rejects a schema on the current client, compare the new error’s field path rather than assuming it is the identical old regression.
This article is based on upstream issue and release evidence. It does not claim an Ofox production reproduction or a measured success rate across gateways.
Why “Anthropic-compatible” is not enough detail
Compatibility can cover authentication, message envelopes and streaming while still differing in accepted JSON Schema features. The failure reported upstream concerns how a validator handles the pattern in a built-in tool definition. It is different from the selected model’s ability to reason about code.
Do not blindly edit a generated regular expression or disable validation in production. Such a change can accept unintended values or hide another incompatibility. Prefer the upstream client fix, and escalate a remaining minimal example to the provider with secrets removed.
When reporting the problem, include only the smallest schema fragment needed to show the rejected construct, not an entire private project prompt. The provider can investigate the validator without receiving source code, environment variables or the full conversation history.
Keep other 400 errors separate
Our missing tool_result guide covers interrupted or malformed tool exchanges. The thinking signature guide covers a different set of message-preservation problems. Neither should be replaced by the Artifact explanation unless the error evidence matches.
A useful support note states the observed failure first: client version, endpoint type, rejected field and exact error. “Claude Code does not work” omits the details that distinguish a fixed client regression from an ongoing provider issue.
Frequently Asked Questions
- Which release fixed the Artifact pattern regression?
- The official changelog records the fix in 2.1.268. Use a supported current client rather than downgrading just to that historical version.
- Should I rotate my API key for this error?
- A schema validation error is not evidence that a key is invalid. Investigate authentication separately if the response points to it; rotating credentials is not the documented fix for this pattern regression.
- Does every custom-endpoint 400 have this cause?
- No. Match the schema field, client version and error text. Tool-result ordering, unsupported parameters and thinking signatures require their own checks.
