[staticvar]

On asking for user input during implementation, it's best to use this when you have a plan sufficiently written up that you can point it to. To prep that plan, you can also use cook to iterate on the plan for you. Having Claude Code use `/cook` directly is nice because it watches what the subagents are up to and can speak for them, although Claude can't speak to the subagents running through cook.

On permissions, by default, when it runs instances of Claude they will inherit your Claude's permissions. So if there is no permission to `rm -rf /`, Claude will just get denied and move on. Using the docker sandbox option (see bottom of page), then it runs inside that `--dangerously-skip-permissions` and get more stuff done (my preferred option). The hard part about that is it means you need to set up the Docker sandbox with any dependencies your project needs. Run `cook init` and edit the `.cook/Dockerfile` to set those up.

[trumbitta2]

Re: So if there is no permission to `rm -rf /`, Claude will just get denied and move on.

Until it doesn't and it finds a way to work around the restriction. Lots of stories around about that.

[staticvar]

I would be interested in which stories you are thinking of. Stories of Claude breaking out of the restrictions set in its sandbox or stories of people not configuring Claude's sandbox correctly?

[trumbitta2]

Latest one: https://ona.com/stories/introducing-veto-security-for-the-ne...

[staticvar]

> We told Claude Code to block npx using its own denylist. The agent found another way to run it and copied the binary to a new path using /proc/self/root to bypass the deny pattern. When Anthropic's sandbox caught that, the agent disabled the sandbox. No jailbreak, no special prompting. The agent just wanted to eagerly finish the task.

I wish that article went into more detail about that attack. But I believe it, the extent that the permissions are easy to get wrong in your claude setttings. For example: https://www.youtube.com/watch?v=3CSi8QAoN-s&lc=UgwFNAh5fvDGJ...