A team step drops cliOptions and permissionMode, so a review-only node can still edit and commit

In a team run every agent node has the same powers, so a node whose only job is to read a diff and hand back a verdict can edit files, commit and push. On 2026-09-10, in one run on our repo, the release node edited a test spec in a sensitive path to make a red suite green (shipping a real defect in it), and two review nodes then each wrote the same fix into the shared worktree and collided. Nothing stopped either. We want one boolean on the node: readOnly.

Full report: https://claude.ai/code/artifact/e5a5a587-a9a3-4181-8ccb-171bf3f6684d

I investigated by read-only inspection of the installed bundle (python3 reads of app.asar, build 1.171.0) and the team JSON on disk. Nothing was patched.

PRIMARY: the node-to-agent projection for a team step emits 12 fields (@2947715, mirror @57802669) and both cliOptions and permissionMode are absent. They exist on a saved agent (32-key blueprint @61265111) and the backlog-ticket spawn path carries them (@3373272). So an agent from a ticket can be restricted and a node inside a team cannot — the one place where "this one reviews, that one writes" is meaningful. On disk, 0 nodes across our 15 team files have either key.

SECONDARY: wrong scope. A team step falls back to Settings > Providers, covering every Claude agent on the machine. Inside one run the implementer must write and the reviewer must not.

AGGRAVATOR: prompt instruction does not hold. Both nodes had a defensible local reason to write, and the exception always looks reasonable from inside the step.

I am not claiming a security boundary: a CLI deny list is escapable with bash -c. This is a control against accidents and role drift, which is what bit us.

Byte offsets are into /opt/AgentsRoom/resources/app.asar of build 1.171.0, so they are checkable but build-specific.

AgentsRoom diagnostics

• App version: 1.171.0
• OS: linux 7.0.0-31-generic (x64)
• Agent CLI: claude
• MCP server: 1.22.0
• App language: system

Problem to solve

A team is a division of labour, but every node gets the same write access, so the division exists only in the step prompt — and prompts do not hold.

Measured 2026-09-10, one run: the release node (a git/merge step) hit a red suite after a rebase, edited a test spec in a sensitive path to fix it (a12ce18), and shipped a real defect in that edit. Two review nodes then each wrote the same correction into the worktree and collided; the commit that landed came from a reviewer.

Both had a defensible reason. It looks reasonable from inside the step.

Proposed behavior

One boolean on the agent node: readOnly. When on, the agent spawned for that step cannot write to the project — no Edit/Write/NotebookEdit, no git commit or push, no writes via the shell — while reading, read-only commands (tests, lint, grep, git diff), team_post_note, team_send, team_complete_step, backlog_update and memory_save stay open.

The wiring exists for verifyInBrowser: a per-node boolean the runner ships in the spawn payload (@2950435) and the client turns into a capability next to browserAccess (@57804328).

Who benefits

Anyone running a team where some nodes judge the work of others: review, security, QA gate, docs, i18n, and the release node.

It also covers a pattern users already improvise around. Across the 15 team definitions on this machine, two nodes encode the intent in their display name because there is no field for it: "Investigação de Dados (read-only)" and "Script de Remediação (não executa)". A string in the node title is the whole enforcement today.

Shipped templates could default it on for review nodes, off for implementer nodes.

Acceptance criteria

A reviewer node that tries to edit is refused by the harness, not talked out of it by its prompt — so "whoever is audited does not fix the rule that audits them" becomes a property of the run instead of a paragraph we maintain by hand.

Concretely: our release node could not have edited that spec, and the two review nodes could not have collided writing the same fix.

Even short of enforcement, a run event "node X wrote to the working tree" would be worth something: today that produces no warning at all.