Bug: PolicyFlags lost after deserializePermissionAccount

[bergusman]

Bug: PolicyFlags lost after deserializePermissionAccount

Problem

When serializing a KernelAccount that uses toPermissionValidator with a custom flag (e.g. PolicyFlags.NOT_FOR_VALIDATE_SIG), the flag is not preserved through the serialize/deserialize cycle.

After deserializePermissionAccount, the reconstructed validator uses the default flag value, causing a mismatch in enableSig — which makes the resulting account unable to send UserOps.

Reproduction

const approval = await serializePermissionAccount(
  await createKernelAccount(client, {
    plugins: {
      sudo: ownerValidator,
      regular: await toPermissionValidator(client, {
        // ...
        flag: PolicyFlags.NOT_FOR_VALIDATE_SIG,
      }),
    },
    kernelVersion,
    entryPoint,
  })
);

const account = await deserializePermissionAccount(
  client,
  entryPoint,
  kernelVersion,
  approval
);

// UserOp fails: enableSig mismatch
await account.sendUserOperation({ ... });

Root Cause

serializePermissionAccount does not include the flag field from the permission validator in the serialized payload. Consequently, deserializePermissionAccount reconstructs the validator without it, defaulting to PolicyFlags.FOR_ALL_VALIDATION.

Impact

Any flow that relies on not default FOR_ALL_VALIDATION (e.g. session keys used purely for execute without signature validation) is broken when accounts are serialized and shared between server and client.

Fix

Include flag in the serialized permission account data and pass it back to toPermissionValidator during deserialization.

Fix suggestion: #262