Decide whether the built-in agent should offer bash by default

[tosinamuda]

Decision to make

Compose's built-in agent offers bash by default. The chain:

fact	where
bash is mutating: true	agent-harness tools/shell.rs
mutating tools are withheld in Ask, offered in Edit	tools/mod.rs
Compose maps allowEdits → "code" (Edit)	src/app/store/chatSend.ts
allowEdits defaults to true	src/app/store/harnessConfig.ts
Compose sets no tool policy	no PermissionRule or disabled_tools in src-tauri/

So out of the box, a markdown notes app can run arbitrary shell commands as the user, driven by a local model.

Why it is not urgent

Two things landed that remove the sharpest edge:

• the provider key is passed to the harness as a value, so it never enters the environment
• the shell's environment is deny-by-default, so other secrets (AWS_ACCESS_KEY_ID, DATABASE_URL, SSH_AUTH_SOCK) are withheld

Why it is still open

Neither is confinement. The tool still runs as the user, so cat ~/.ssh/id_ed25519 and curl exfiltration are unaffected. Real containment needs an OS sandbox — see getlatentic/agent-harness#45.

Options

1. Disable bash — one line, now that agent-harness supports it:

   disabled_tools: vec!["bash".into()],

   Writing tasks are served by read, glob, grep, list, write, edit. Also trims the tool schemas, which measurably hurt small local models (agent-harness#42).

2. Keep it, gated — offer it only when the user opts in, with the trade stated plainly.

3. Keep it, and wait for the sandbox — accept the current exposure until agent-harness#45 lands.

Worth weighing

Codex sandboxes its shell because a coding agent genuinely needs one. Compose's users are writers, not developers, and the agent's job is notes. A capability nobody asked for is not worth a security surface — but the same shell is genuinely useful for anyone who does want it, which is why this is a decision rather than a fix.