🐛 Bug: react-core / mcp-apps-renderer .d.mts written for Zod 3 break type-checking when the app's zod is v4 (1,683 errors with skipLibCheck: false) · Issue #7816 · CopilotKit/CopilotKit · GitHub
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
🐛 Bug: react-core / mcp-apps-renderer .d.mts written for Zod 3 break type-checking when the app's zod is v4 (1,683 errors with skipLibCheck: false) #7816
In an empty directory: npm init -y && npm install @copilotkit/react-core@1.79.0 react@19 react-dom@19 typescript@5 @types/react@19 @types/react-dom@19
(npm installs zod 4.6.7 at the top level, brought in by @ag-ui/core; zod@3.25.76 stays nested under @ag-ui/client and @copilotkit/shared.)
CopilotKit's own declarations type-check against the zod the app has, since the peer range is zod >= 3.25.
❌ Actual Behavior
1,687 errors, of which 1,683 come from CopilotKit declarations:
1,677 in @copilotkit/mcp-apps-renderer/dist/content-schema.d.mts
6 in @copilotkit/react-core/dist/copilotkit-*.d.mts (OpenGenerativeUIContentSchema)
e.g.
content-schema.d.mts(5,45): error TS2707: Generic type 'ZodObject<Shape, Config>' requires between 0 and 2 type arguments.
content-schema.d.mts(7,27): error TS2707: Generic type 'ZodArray' requires between 0 and 1 type arguments.
content-schema.d.mts(7,62): error TS2344: Type 'string' does not satisfy the constraint 'readonly SomeType[]'.
Cause: both packages declare zod >=3.25 as a peer but build against Zod 3 (devDependency ^3.25.76 in mcp-apps-renderer), so the emitted .d.mts uses Zod 3 type shapes behind import { z } from "zod". In an app whose zod is 4, those resolve to Zod 4 types.
zod/v3 exists in every version the peer range allows (3.25+ and 4). Changing just those two imports in the published files to import { z } from "zod/v3" removes all 1,683 errors. The 4 errors left are in third-party declarations, and one of them is a separate CopilotKit packaging issue I'll file on its own. In source, the imports are in packages/mcp-apps-renderer/src/content-schema.ts, packages/mcp-apps-renderer/src/session.ts and packages/react-core/src/v2/components/OpenGenerativeUIRenderer.tsx (unchanged on main @ 07226a2). Switching them to zod/v3 also changes which Zod builds those schemas at runtime, so I'd like to know if that's the approach you want before opening a PR.
With skipLibCheck: true (the Vite template default) none of this shows, which is probably why it has gone unnoticed. The validate-dts-imports gate from #6674 doesn't catch it either: it reports mcp-apps-renderer as clean, because zod is a required peer and resolves, just to a different major version. Related runtime fixes for Zod 4 in the same schemas: #4295 / #5025.
Screenshots
No response
𝌚 CopilotKit Version
@copilotkit/react-core@1.79.0
📄 Logs (Optional)
node_modules/@copilotkit/react-core/dist/copilotkit-DFMMPW2I.d.mts(2036,46): error TS2707: Generic type'ZodObject<Shape, Config>' requires between 0 and 2 type arguments.
node_modules/@copilotkit/react-core/dist/copilotkit-DFMMPW2I.d.mts(2041,23): error TS2707: Generic type'ZodArray<T>' requires between 0 and 1 type arguments.
⚠️ This is an AI-generated response. We've escalated this to our engineering team — someone will follow up in this thread shortly.
The diagnosis is correct: the .d.mts files in @copilotkit/mcp-apps-renderer and the OpenGenerativeUIRenderer chunk of @copilotkit/react-core import from "zod" but were built against Zod 3 type shapes. When the app's top-level zod resolves to Zod 4, those type parameters no longer match, producing the 1,683 errors you're seeing.
The zod/v3 compat path is the right direction — Zod 4 ships it precisely for this scenario — but whether the fix lands there or via a tighter peer declaration or a separate bundled copy is a call for the maintainers. Engineering will need to verify and decide the approach before a PR makes sense.
In the meantime, the only user-side workaround that avoids touching CopilotKit internals is pinning your app's top-level zod to 3.x (e.g. "zod": "^3.25.76" in package.json) so the peer resolves to the version the declarations were built against. That's a real constraint if something else in your dependency tree requires Zod 4, but it removes all 1,683 errors without skipLibCheck.
🤖 Generated by CopilotKit AI Support · Documentation
2. The zod/v3 compat path is the right direction — Zod 4 ships it precisely for this scenario — but whether the fix lands there or via a tighter peer declaration or a separate bundled copy is a call for the maintainers. Engineering will need to verify and decide the approach before a PR makes sense.
Let me know what is preferred and I can submit a PR for it.
Activity
copilotkit-outpost-bot commentedon Oct 14, 2026
The diagnosis is correct: the
.d.mtsfiles in@copilotkit/mcp-apps-rendererand theOpenGenerativeUIRendererchunk of@copilotkit/react-coreimport from"zod"but were built against Zod 3 type shapes. When the app's top-levelzodresolves to Zod 4, those type parameters no longer match, producing the 1,683 errors you're seeing.The
zod/v3compat path is the right direction — Zod 4 ships it precisely for this scenario — but whether the fix lands there or via a tighter peer declaration or a separate bundled copy is a call for the maintainers. Engineering will need to verify and decide the approach before a PR makes sense.In the meantime, the only user-side workaround that avoids touching CopilotKit internals is pinning your app's top-level
zodto3.x(e.g."zod": "^3.25.76"inpackage.json) so the peer resolves to the version the declarations were built against. That's a real constraint if something else in your dependency tree requires Zod 4, but it removes all 1,683 errors withoutskipLibCheck.🤖 Generated by CopilotKit AI Support · Documentation
Was this helpful? React with 👍 or 👎
Laptopmini commentedon Oct 14, 2026
Let me know what is preferred and I can submit a PR for it.
fix(runtime-client-gql): declare the packages its published types imp…