What happens
Using opencode/union-alpha (Zen, Anthropic-wire), any chat breaks with a deterministic pre-inference 400 as soon as the offending MCP tools are connected — no tool call needed, the schemas are sent as available tools:
Streaming response failed: [invalid_request_error] Invalid JSON schema: regex lookaround is not supported. Found at $.properties.email.pattern.
The offending schemas
Live tools/list census of my connected MCP servers (338 tools total across supabase 13 / auk-brain 208 / auk-relapse 78 / farero_host 39) finds exactly two tools carrying a lookaround, both on the same MCP server:
customer_find — $.properties.email.pattern
workspace_addMember — $.properties.email.pattern
Both use:
^(?!\.)(?!.*\.\.)([A-Za-z0-9_' + \-\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\-]*\.)+[A-Za-z]{2,}$
(two negative lookaheads). This matches the error path exactly.
Why it only hits union-alpha, and why it strikes mid-chat
#32489 added sanitizeOpenAISchema (mirroring Codex lowering, drops pattern among other keys), but it is applied only when model.api.npm === "@ai-sdk/openai" || "@ai-sdk/azure" (packages/opencode/src/provider/transform.ts, tools path). union-alpha runs over Zen on the Anthropic adapter, so it bypasses the sanitizer and forwards the raw lookaround to Zen's validator.
The delayed failure is a connect-timing artifact: early turns go out before the OAuth remote MCP finishes connecting (fewer tools attached, requests succeed); once it connects, every subsequent request carries the two schemas and fails. Retrying cannot help.
Suggested fix
Apply the same schema lowering to the Zen provider path (or to every adapter whose upstream rejects lookarounds), with a regression test carrying a lookaround-bearing pattern through the Zen tools path.
Workaround (verified config option)
Follow-up to #32488 (that fix is intact — this is the Zen/Anthropic-adapter gap beside it, not a reopen).
What happens
Using
opencode/union-alpha(Zen, Anthropic-wire), any chat breaks with a deterministic pre-inference 400 as soon as the offending MCP tools are connected — no tool call needed, the schemas are sent as available tools:Streaming response failed: [invalid_request_error] Invalid JSON schema: regex lookaround is not supported. Found at $.properties.email.pattern.The offending schemas
Live
tools/listcensus of my connected MCP servers (338 tools total across supabase 13 / auk-brain 208 / auk-relapse 78 / farero_host 39) finds exactly two tools carrying a lookaround, both on the same MCP server:customer_find— $.properties.email.patternworkspace_addMember— $.properties.email.patternBoth use:
^(?!\.)(?!.*\.\.)([A-Za-z0-9_' + \-\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\-]*\.)+[A-Za-z]{2,}$(two negative lookaheads). This matches the error path exactly.
Why it only hits union-alpha, and why it strikes mid-chat
#32489 added
sanitizeOpenAISchema(mirroring Codex lowering, dropspatternamong other keys), but it is applied only whenmodel.api.npm === "@ai-sdk/openai" || "@ai-sdk/azure"(packages/opencode/src/provider/transform.ts, tools path).union-alpharuns over Zen on the Anthropic adapter, so it bypasses the sanitizer and forwards the raw lookaround to Zen's validator.The delayed failure is a connect-timing artifact: early turns go out before the OAuth remote MCP finishes connecting (fewer tools attached, requests succeed); once it connects, every subsequent request carries the two schemas and fails. Retrying cannot help.
Suggested fix
Apply the same schema lowering to the Zen provider path (or to every adapter whose upstream rejects lookarounds), with a regression test carrying a lookaround-bearing
patternthrough the Zen tools path.Workaround (verified config option)
Follow-up to #32488 (that fix is intact — this is the Zen/Anthropic-adapter gap beside it, not a reopen).