Fixes #5195. Related ecosystem evidence: nicoespeon/zod-v3-to-v4#30 and #35 — the official v3→v4 migration tool had to drop v3's input generic when rewriting SafeParseReturnType<I, O> to ZodSafeParseResult<O>, and explicitly flagged this issue as the upstream gap.

Discussion seed in #5195 (comment). Opening the PR for concrete review surface; happy to close it if the maintainer would rather keep the current shape.

Problem

When a schema's input differs from its output (pipe / transform / codec), safeParse(...).error is currently typed as ZodError<output> even though the issues it carries are paths in the input space (validation runs there). z.treeifyError(result.error) therefore infers a tree keyed by output properties that don't exist at runtime, while the input-keyed properties that DO exist are flagged as type errors.

OP's reproduction:

type A = { a: number };
type B = { b: string };
const pipe = z.object({ a: z.number().max(9) })
  .pipe(z.transform<A, B>(({ a }) => ({ b: a.toString() })));

const errors = pipe.safeParse({ a: 10 })?.error;
if (errors) {
  z.treeifyError(errors).properties?.a; // ← flagged as a type error, but real
  z.treeifyError(errors).properties?.b; // ← accepted, but does not exist at runtime
}

The maintainer-suggested workaround z.treeifyError<unknown>(errors) is fine for one-off code but doesn't scale into codemods or library APIs that need typed error trees per schema.

Fix

Generalise the success/error split so error carries the input generic, defaulting to the output for backward compatibility:

// before
export type SafeParseResult<T> = SafeParseSuccess<T> | SafeParseError<T>;

// after
export type SafeParseResult<O, I = O> = SafeParseSuccess<O> | SafeParseError<I>;

Then thread core.input<this> through:

• safeParse / safeParseAsync / spa overloads on ZodType (classic) and ZodMiniType (mini)
• safeEncode / safeDecode (and async variants) — error keyed by the value being parsed
• inferFlattenedErrors / inferFormattedError v3-compat aliases so error.flatten() / error.format() typings agree

The two-generic shape mirrors v3's SafeParseReturnType<I, O> exactly, which v4 collapsed. Codecs and migrations that used to work in v3 keep working with the same intent.

Backward compatibility

• ZodSafeParseResult<X> (single arg) defaults to <X, X> — identical typing for the 98% of schemas where input === output.
• result.success / result.data typings unchanged.
• result.error typing only changes for pipe / transform / codec schemas, where the previous typing was unsound: any user code that relied on it was already broken at runtime (the OP's reproduction is exactly that case).

Tests

• packages/zod/src/v4/classic/tests/safeparse-error-input.test.ts — locks in the OP reproduction (tree keyed by input, output keys rejected) and verifies the one-arg form still types correctly for simple schemas.
• Existing inferFlattenedErrors test in error.test.ts now compiles cleanly (it was already asserting the correct runtime shape — only the inferred type was lying).

Local results

Test Files  1 failed | 338 passed (339)
     Tests  1 failed | 3792 passed (3793)
Type Errors no errors

The single failing test (src/v4/classic/tests/datetime.test.ts > redos checker) is not caused by this PR. It's a recheck library bug on Windows that fires for every contributor on Windows, regardless of branch — recheck's jar resolution uses a forward-slash regex that no-ops on backslash paths. This is independent of safeParse typings and is fixed by #5919. Same test passes on Linux CI today.

Diff stats: 7 files, +62 / -25 (most of which is overload signatures gaining a second generic).

Note about CI

CI on this PR will also show a red Test with TypeScript latest job, also unrelated to this change: it's the repo-wide baseUrl deprecation that surfaces under TS 6 since e58ea4d. Every PR opened since that commit fails the same way. #5921 (small workflow patch) addresses it; once that lands the noise on this PR will go away.

Sanity-checked locally on TS 6.0.3 with #5919 + #5921 patches applied: full suite green, safeparse-error-input.test.ts passes, inferFlattenedErrors test passes, no type errors anywhere in the repo.