🐛 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
Skip to content

🐛 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

Open

Description

@Laptopmini

♻️ Reproduction Steps

  1. 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.)
  2. index.tsx:
import { CopilotKit } from "@copilotkit/react-core";
export const App = () => <CopilotKit runtimeUrl="/api/copilotkit">{null}</CopilotKit>;
  1. tsconfig.json:
{ "compilerOptions": { "target": "ES2022", "module": "ESNext", "moduleResolution": "bundler", "jsx": "react-jsx", "strict": true, "noEmit": true, "skipLibCheck": false }, "include": ["index.tsx"] }
  1. npx tsc -p .

✅ Expected Behavior

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.

Activity

  1. copilotkit-outpost-bot commented on Oct 14, 2026

    @copilotkit-outpost-bot

    ⚠️ 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


    Was this helpful? React with 👍 or 👎

  2. Laptopmini commented on Oct 14, 2026

    @Laptopmini
    ContributorAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions