I'm also experiencing this on 3.23.8, as a temporary workaround I'm using a union of string literals:

const myEnum = z.union([z.literal("someValue"), z.literal("otherValue")]);

I've looked into this in the past few days. I believe the problem is not strictly in the Zod code that uses the internal lookup (added here: #2659), but rather in the javascript code that is generated by typescript.

It seems that the TypeScript compiler adds some initialization code in the ctor, which stores the private members (like #cache) on a static WeakMap. Later, when accessing those members, the __classPrivateFieldGet __classPrivateFieldGet, which are generated by the compiler and added to the top of the js file, throw if the WeakMap does not have an entry for the current instance.

This means that it's impossible to clone a ZodEnum instance, and I, for one, see this as an unwanted side-effect and actually a bug in Zod.

I have a few suggestions here:

1. Making the optimization configurable (opt-out as needed). I don't expect enums with few values to benefit from the optimization that much.
2. Implementing the lookup in a way that uses exactly the same approach that exists now, just not throw. Effectively, it'll be a lazy-loaded thing.
3. Implementing the lookup as a closure inside _parse instead of a private instance member. I believe this is actually the best approach as it ticks all the boxes and allows cloning. The lookup will be initialized on the first call, like today, but will allow cloning.