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.
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?
> 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.
If you impl this as a backend and connect to Telegram bots, agents can just do `$ ask "Should I do this?"` for agent→human and `$ alert "this thing blocked me"` for coder→planner. That's what I'm actually doing — I have 1 manager + 3 designers + 1 researcher + 2 debugger + 1 communicator + any number of temporal coders/reviewers in my setup, all connected to taskwarrior for task-driven-dev
That is pretty cool building the whole dev team of agents and is it still with a star topology of a Manager agent interacting with all the other subagents?
I usually spawn 1 Mother Agent in a star topology with 3 subagents Planner, Reviewer, Implementer and them let them talk using Claude built-in agent tool. But the best thing I think was probably that a "do-nothing" setup wizard is part of the workflow.
Yeah the pipeline runs effectively and I'm able to be in the loop when the loop needs me.
In my setup there are two planes — manager and worker. On the manager plane, all primary agents form a mesh with p2p communication. Each designer connects to 1 or more workers in a star topology, since workers may have questions or get blocked while executing a plan.
The limitation of the built-in agent tool is it doesn't allow nested subagent spawning. But it's normal for a designer or researcher to need subagents — when a plan is done, I use a plan-review-leader agent to review it. If you try mother → planner → plan-review-leader → plan-vs-reality-validator, the nesting gets deep fast and blocks your manager from doing other work.
I like your 2-plane mesh setup with multiple top-level agents and 'you' on the manager plane mesh that are able to communicate via a daemon mediated communication.
The daemon is the Telegram bridge, the tmux router, the CI status deliverer, and the cleanup coordinator all in one process. It allows for cross star topology communication unlike MoMa that basically just corresponds to a single manager and is similar to your plan-review-leader agent living in the manager plane if that one was isolated.
My previous concern was that maybe you would face a timeout in case user input was needed during a pipeline run, and in a case where the user was too slow to provide an answer through telegram (I imagine during the night), but maybe even github pipelines can be set to wait unlimited.
I really like the setup, and exactly I also faced the no nested agent spawning limit by Anthropic for Claude Code built-in agent tooling, that dictates the star topology in the first place.
I use the git worktree as well for every MoMa agent and they all live in Linux screen session. Maybe I should consider going to tmux myself instead of screen as I understand all your agents in top-level manager plane also are just tmux sessions.
using a single plan-reviewer would be slow when there are multiple aspects to review. That's why a local star topology with a plan-review-leader is needed: it spawns multiple reviewers in parallel, each focused on a different aspect.
Yeah, with a 2 plane topology you are able to inherit concurrency as you for instance just hand off work from a designer agent to the plan-review-leader that spawns any number of reviewers in a star topology.
By default it's locked down to the permissions you have granted in your Claude config. If you use the docker sandbox mode, then you can really let it fly as it can issue more commands in a safer environment.
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.