[Regression 2.1.265] Built-in Artifact database tool ships JSON-Schema `pattern` with `\p{...}` escapes — strict validators reject every request (400, "not a regex")

## Summary

**Regression in 2.1.265, still present in 2.1.266:** the built-in Artifact database tool's `input_schema` gained a JSON-Schema `pattern` on its collection / document identifier fields that uses Unicode property escapes (`\p{...}`). Endpoints whose schema validators implement a strict regex subset reject the entire request with `400 Invalid JSON schema: ... is not a "regex"`. The pattern is valid ECMA-262 (with the `u` flag) and is accepted by Anthropic's own API, so first-party use never sees this — but any strict-validator-compatible endpoint fails **every** request carrying the tool. Because the tool ships in every request, the first turn fails and the session is fully unusable regardless of user input.

The offending pattern:

```text
^(?!__.*__$)[^\p{Cc}\p{Cf}\p{Zl}\p{Zp}"\\./[\]]{1,200}$
```

(intent: reject dunder-wrapped identifiers, control/format/separator characters, `" \ . / [ ]`, cap at 200 chars.)

## Repro

1. Run Claude Code **2.1.265** (or **2.1.266**) with requests routed to a third-party Anthropic-compatible endpoint whose JSON-Schema validator does not support Unicode property escapes (`\p{...}`).
2. Start an interactive session and send any prompt.
3. The first turn fails deterministically, e.g.:

```text
API Error: 400 Invalid JSON schema: "^(?!__.*__$)[^\p{Cc}\p{Cf}\p{Zl}\p{Zp}\"\\\\./[\\]]{1,200}$" is not a "regex"
```

(exact error wording varies by gateway; the invariant is a 400-class schema rejection naming that pattern.)

**Control:** the identical session shape on **2.1.263** succeeds with zero schema errors.

**Minimal wire repro:** send any `/v1/messages` request carrying the built-in Artifact database tool schema exactly as shipped → 400. Re-send with only the two identifier `pattern` keywords (collection / document id) stripped → accepted. No other change needed.

## Expected vs Actual

- **Expected:** the shipped tool schemas validate on any spec-conformant Anthropic-compatible endpoint; an identifier-validation refinement never bricks sessions on strict validators.
- **Actual (2.1.265 / 2.1.266):** every request carrying the Artifact database tool is rejected by strict validators before inference, so the session fails on turn one for any input. 2.1.263 (no such `pattern`) works.

## Root cause (with evidence)

Binary forensics of the linux-x64 harness tarballs:

- **2.1.263:** the entire validation block is absent — no such pattern anywhere in the binary.
- **2.1.265:** the string appears **twice**:
1. once as a JS validator with the `u` flag — `/^(?!__.*__$)[^\p{Cc}\p{Cf}\p{Zl}\p{Zp}"\\./[\]]{1,200}$/u` — in the Artifact database tool code, adjacent to the `get` / `list` / `query` and `set` / `update` / `delete` `db_op` handling;
2. once as a bare string in a validation/spec table, consistent with wire emission as the JSON-Schema `pattern` for the collection / document identifier fields.
- **2.1.266** (npm `next` tag): present **byte-identical** — not fixed.

So the regression is the introduction (in 2.1.265) of a `\p{...}`-dependent `pattern` that is both enforced locally (JS, where `/u` makes it legal) and emitted on the wire (JSON Schema, where the receiving validator's regex dialect governs). Strict validators that don't implement Unicode property escapes reject the schema itself, hence the deterministic first-turn 400 on any session carrying the tool.

## Suggested fix

In order of preference:

1. **(Recommended, cleanest) Rewrite the segment pattern without `\p{...}` using explicit code-point ranges.** The validation intent is fully expressible in portable syntax, e.g. `\p{Cc}` → `U+0000–U+001F, U+007F–U+009F`; `\p{Zl}` → `U+2028`; `\p{Zp}` → `U+2029`; `\p{Cf}` → the explicit Cf list generated from the project's pinned Unicode version (its membership is version-dependent, so generate it programmatically rather than hand-transcribing). This keeps the client-side guardrail **and** maximizes validator compatibility, with zero endpoint-sniffing.
2. **Drop `pattern` from those fields.** Safe if server-side validation is already authoritative (the client pattern is then defense-in-depth / early UX feedback). Cheapest, but loses the early client-side rejection the pattern was presumably added for.
3. **Withhold `pattern` on non-first-party endpoints.** Works around the failure but introduces base-URL sniffing (fragile behind proxies / localhost / custom gateways) and schema drift between endpoints. Prefer a uniform portable schema (option 1) over endpoint-conditional schemas.

Verification for whichever is chosen: assert in CI that **every** shipped built-in tool `pattern` compiles under both a full ECMA-262-with-`u` engine and a strict-subset engine without `\p{...}` support (e.g. RE2 or equivalent), so no future pattern reintroduces the class.

## Edge cases considered

- **Other tools may carry `\p{...}` too.** The fix should audit all shipped `input_schema` patterns, not just the two Artifact identifier fields — one portable-pattern policy for every built-in tool, with the CI assertion above locking it.
- **ECMA-262-full vs strict-subset validators.** The pattern is legal input (Anthropic accepts it); the failure is a dialect gap. Target the lowest common denominator: portable syntax that is simultaneously valid ECMA-262 and valid under strict subsets, with no flag dependence (the rewritten pattern must not rely on `/u` semantics to mean what it means).
- **Drop vs rewrite.** Dropping is a contract change for anyone validating identifiers locally against the shipped schema; rewriting preserves the documented intent (dunder guard, excluded characters, 200-char cap) while restoring compatibility — which is why option 1 is recommended.
- **Backward compatibility of stored identifiers.** Identifiers created under the pattern-less schema (≤ 2.1.263) already exist; the read paths (`get` / `list` / `query`) must not retroactively reject them, and the rewritten pattern's accept-set must match the server-side rules exactly (including the dunder guard and the 200 limit) or previously-valid reads break.
- **Length semantics and astral-plane input.** Keep the 200-unit semantics identical through the rewrite (UTF-16 code units vs scalar values vs bytes must not silently change); cover combining marks, `U+FEFF` / `U+200B`-style Cf edge cases, and supplementary-plane identifiers in tests.
- **Single-tool blast radius.** A schema-level rejection of one tool's pattern fails the whole request, not just calls to that tool — so any non-portable construct anywhere in the always-shipped tool set is session-fatal. That's what makes this class worth a registry-wide CI gate rather than a one-spot fix.

## Environment

- Claude Code **2.1.265** (regressed) and **2.1.266** (still present, byte-identical); last working **2.1.263**.
- Platform observed: linux-x64 harness build; failure is endpoint-determined, not OS-specific.
- Endpoint: third-party Anthropic-compatible `/v1/messages` endpoint with a strict JSON-Schema validator (no `\p{...}` support). First-party Anthropic API accepts the schema (valid ECMA-262 with `u`).

## Related

- #92964 — closest neighbor: same `pattern`, same version bracket, bisected from the request-body side (interactive fails, stripped-pattern replay succeeds). This filing adds the binary-side root cause (dual occurrence: JS `/u` validator + wire-emitted spec-table string; absent in 2.1.263, byte-identical in 2.1.266) and the portable-rewrite recommendation with edge cases.
- #92900 — nearby in symptom space (tool schemas breaking sessions) but a different defect (boolean property schemas in MCP tool conversion, SDK-side tool dropping — silent, partial). Mentioning only to aid triage; not the same bug.
- #84056 — interactive-only 400s from `input_schema` keywords on strict backends (MCP `oneOf`/`allOf`/`anyOf`); same failure class (schema-dialect gap bricks the whole request), different construct.

Start by locating the built-in Artifact database tool code and its input_schema definitions, especially the get/list/query and set/update/delete db_op handling mentioned in the report. Audit every shipped tool pattern, then run the schema-validation checks against both a full ECMA-262 engine and a strict-subset engine. Done means strict-compatible schemas preserve the stated identifier behavior and CI prevents future non-portable patterns.

Scritto dal modello di indicizzazione a partire dal testo della issue.