Zod 4 not executing check and refine after omit and pick

[rhinodavid]

Consider this schema with a check that fails if the value of hello is not world.

import { z } from "zod/v4";

const checkSchema = z
  .object({
    number: z.number(),
    hello: z.string(),
  })
  .check(({ value, issues }) => {
    if (value.hello !== "world") {
      issues.push({
        code: "custom",
        message: "Hello must be 'world'",
        input: value.hello,
      });
    }
  });

When I parse this it behaves as expected:

const withNumberCheck = checkSchema.safeParse({
  number: 42,
  hello: "not world",
});

// {
//   success: false,
//   error: ZodError: [
//     {
//       "code": "custom",
//       "message": "Hello must be 'world'",
//       "path": [
//         "hello"
//       ]
//     }
//   ]
// }

However, if I omit the number key the check doesn't execute:

const withoutNumberCheck = checkSchema.omit({ number: true }).safeParse({
  hello: "not world",
});

// Without number: { success: true, data: { hello: 'not world' } }

I've confirmed that this behaves the same with refine. It also behaves the same if one uses pick instead of omit.

In Zod v3 trying to pick/omitafter a refine raises a type error:

Property 'pick' does not exist on type 'ZodEffects<ZodObject<{ number: ZodNumber; hello: ZodString; }, "strip", ZodTypeAny, { number: number; hello: string; }, { number: number; hello: string; }>, { ...; }, { ...; }>'

I'm unsure what the intended behavior here is supposed to be. It seems like the options are:

1. Execute the refine/check with values that might now be undefined. This seems contrary to the sprit of Zod since the types on the check are no longer correct.
2. Raise the type error like in Zod v3. This seems like a better solution.

I poked around on the issues and discussion and didn't see this issue noted anywhere. Hopefully I'm not duplicating a known issue here. Thanks in advance to whomever looks into this.

[dosubot[bot]]

Hi @rhinodavid! I'm Dosu and I’m helping the zod team.

This is expected behavior in Zod v4: when you use .omit or .pick on a schema that has .check or .refine, the resulting schema does not retain those validation effects. This is a change from Zod v3, where the type system prevented chaining .refine(...).pick(...) and would raise a type error instead. In v4, refinements and transformations are layered as effects, but object schema transformations like .pick and .omit do not automatically preserve those effects, so your custom validations are lost after these operations. This is working as designed and is not considered a bug in v4 (source).

If you need to apply custom validation to a picked/omitted schema, you should re-apply your .check or .refine after the transformation, or consider using a combination of .custom and .pipe for more granular control (source).

Let me know if you need a code example or want to discuss possible workarounds for your use case. If this answers your question, please feel free to close the issue!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[rhinodavid]

Well kudos to you @dosu. I'm sure there are wider reasons for this decision but man it is scary. I feel like I need a lint rule to disable pick and omit because it's going to silently disable validations.

[dosubot[bot]]

Totally get where you're coming from—this change in Zod v4 can feel a bit risky, especially if you're used to v3's stricter type safety. The main reason for this shift is that refinements and checks are now encapsulated inside the schema, and when you use .pick or .omit, Zod intentionally strips away all custom validation effects (like .check and .refine). This avoids running checks on data shapes that may no longer match the original intent, but it does mean you need to reapply any custom validations after transforming your schema. This design keeps things predictable and avoids subtle type mismatches, even if it feels a bit "scary" at first [source].

If you want to keep type inference and custom validation together, you can use .custom and .pipe to reapply your checks after a transformation. Let me know if you want a concrete example or want to talk through a workaround for your use case!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[rhinodavid]

I had closed this after the robot pointed me to #4427 but the discussion there is adjacent but not the same, as that one occurs at the type level.

Suppose we've created an entity "record" with a check:

const zRecord = z.object({
  id: z.uuid(),
  property: z.string()
}).refine(({ property }) => property === "something");

Here's what I'm afraid of. Someone (me) will create a tRPC endpoint where a "record" gets made. The database will add the ID, so the input to the endpoint will have the ID omitted:

const router = t.router({
  createRecord: t.procedure
    .input(zRecord.omit({ id: true }))
    .output(zRecord)
    .mutation(({ input }) => { return insertRecord(record); })
});

We just disabled the check and the only way to know it is to have a deep understanding of the framework. There are certainly workarounds (don't put the id on zRecord but extend zRecord in the output) but there's no good way to stop a junior dev or someone not paying close attention from falling into this trap.

Otherwise congrats on v4 -- it looks awesome and I'll be excited to upgrade once I can figure out a way to prevent this from happening. I'm especially excited about the built-in JSON schema support.

[aldenquimby]

@rhinodavid where did you land on this? We just upgraded to v4 and are hitting the same issue:

const EventSchema = z.object({
  startAt: DateSchema,
  endAt: DateSchema,
  // ... otherFields ...
})
  .refine(
    ({ startAt, endAt }) => endAt >= startAt,
    {
      error: 'Event cannot end before it starts',
      path: ['endAt'],
      when: ({ value }) => EventSchema.pick({ startAt: true, endAt: true }).safeParse(value).success,
    },
  );

// this will not run the refinement, and there is no lint failure or other indication warning devs
const UhOhSchema = EventSchema.omit({ title: true });

It almost makes us want to go back to zod3, where you were forced to re-run refinements because they couldn't be extended in any way