Claude Code returns 400 on a custom API? Check the Artifact schema

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.

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 --version

If 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.

A complete recovery sequence for the affected client

Start by saving the failing turn’s UTC time, exact error and client version. If a job retries automatically, pause that job through its normal controls: repeatedly submitting the same rejected schema does not help identify the fault. Preserve the workspace and conversation; deleting them would remove useful evidence and is not the documented fix.

On macOS or Linux, these commands identify the executable and its installation health without sending a model request:

command -v claude
claude --version
claude doctor

On Windows PowerShell, use Get-Command claude for the executable location, followed by the same version and doctor commands. Compare the location with the environment that actually failed. An IDE may retain an old process even after the terminal installation changes. A remote development container may have its own executable and release pin.

Choose the update method that owns that installation. The official setup guide documents claude update for supported self-managed installs; Homebrew users update the cask they installed, for example brew upgrade claude-code. An organization-managed installation should use its approved package update. Do not run several package managers in succession: that can create a second installation and leave the original failing process unchanged.

After the update completes, close and reopen the relevant client, run claude --version in that environment again, and record the result. Merely seeing “update complete” is insufficient if the next request still comes from another binary. The target is a supported build containing the 2.1.268 correction, not specifically an old release number.

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.

Use two small checks, with different acceptance criteria

First ask for a short text response in the same configuration. This sends a model request and can use your allowance or incur provider charges. A suitable diagnostic prompt is:

Reply with exactly: connection check
Do not modify files or run commands.

Expected: an ordinary assistant response rather than the original Artifact schema rejection. The exact words test basic response handling, not coding quality. Save any new error independently; a changed error is evidence that the request reached a different validation stage, not necessarily a complete fix.

Second, in a disposable folder containing a harmless sample.txt, ask the client to read that file and report its first line without editing it. This checks the tool workflow you will need for the real task. Verify the reported line against the local file and inspect the client’s tool result. If your normal configuration includes the built-in Artifact definition, preserve that configuration during the retest; disabling it would no longer test the same request construction.

These prompts are suggested tests, not results from our account. Resume the original long task only when the rejected schema is gone and the relevant tool exchange completes. Do not ask the client to edit or deploy the real project just to prove connectivity.

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.

Understand what the validator is rejecting

A JSON document can be syntactically valid while its JSON Schema pattern is incompatible with a particular validator. Consider this simplified illustration, not a copy of the complete upstream tool:

{"type":"string","pattern":"^[\\p{L}]+$"}

The JSON parser sees a string containing a backslash followed by p{L}. Interpreting that string as a regular expression is a second operation, and Unicode property handling depends on the regular-expression engine and its mode. Successfully parsing the JSON therefore cannot demonstrate that the provider accepts the pattern.

Replacing the pattern with .* is not an equivalent repair: it also changes which values the schema accepts. Stripping the tool entirely changes what the client can do. Neither workaround is necessary merely to check whether the upstream client correction resolves your configuration. If you maintain a gateway, reproduce the validation failure in a staging fixture and retain the exact engine/version when investigating compatibility; do not loosen all production schemas to accommodate one historical request.

Escalate only the remaining minimal failure

A useful escalation fits on one screen: “client before X, client after Y, endpoint family, selected model, rejected field path, UTC time, provider request ID, text-only retest result, read-only tool retest result.” Attach the relevant schema fragment only if the provider requests it. Remove tokens, private prompts, repository paths and file contents that are not needed to reproduce validation.

If updating removed the Artifact error but tool results now fail, continue with the tool-result or thinking-signature guide linked at the end of this article. If the same Artifact pattern is still rejected, ask the provider to confirm which schema its validator received and whether a proxy or worker is still using the older client. If a current, clean reproduction still fails, preserve it for an upstream issue rather than labeling every 400 as this regression.

Recovery is complete when the intended client sends the corrected request and your harmless tool workflow succeeds on the intended route. That conclusion is deliberately narrower than “all models work” or “the provider is fully compatible.”

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.