bypassPermissions not supported during streaming mode change?

[EdanStarfire]

Issue:

SDK seems to throw an error if you try to use set_permissions_mode("bypassPermissions") after the session was created without that permission.

error log format is from my app:

set_permission_mode_failed - Cannot set permission mode to bypassPermissions since it is not available

Steps to replicate:

1. Create a ClaudeSDKClient instance with an initial permission mode of default
2. Attempt to use client.set_permission_mode("bypassPermissions") and it'll generate that error.

Questions and Concerns

The code in the library seems to imply that this should be allowed, but it doesn't seem to be working.

Is it possible that this is intentional (cannot move to fully unrestricted from a session that wasn't started that way)?

[ashwin-ant]

By any chance do you have a settings file with disableBypassPermissionsMode set?

[EdanStarfire]

I confirmed that no settings files (user, project, and project local files) have that setting configured. I am working on updating my system to tweak a couple things and enable some more testing / debugging on the off change I just had something broken.

[EdanStarfire]

Okay - did some more testing to verify behavior:

Updated my coding to allow changing the mode the session starts with.

If the streaming session starts in bypassPermissions mode, then it can cycle through all 4 modes without issues dynamically.
Example:

• bypassPermissions (Can delete and run bash commands without prompting), cycle to
• default (Can do read-only things, but prompts to edit or run bash commands), cycle to
• acceptEdits (Can do read and write things, as well as edit, but still prompts for bash commands), cycle to
• plan (can do read-only things, but prompts to ExitPlanMode with a plan before editing or running bash commands), cycle to
• bypassPermissions (Can delete and run bash commands without prompting)

BUT, if I start it with default, acceptEdits, or plan modes, when I cycle to bypassPermissions mode, it looks like it throws that error above and remains in the previous mode, in this case plan.

So this seems like an intentional "prevent escalation to bypassPermissions unless session was started with it". My tooling has a "restart session" function that in theory would be a workaround (detect it wasn't started in bypassPermissions mode and then stop the current agent SDK session, and then resume it with the bypassPermissions), but I'm not sure if the resume honors a new permissions mode and I don't want to implement that unless the above behavior is intended. 😄