docs: harnesses default to inconsistent write/approval behavior (claude vs codex vs zarvis)

[edwin-zvs]

Summary

Harnesses default to different write/approval behaviors, which is surprising when orchestrating a fleet:

Harness	Headless write behavior observed
claude	Wrote files with no approval prompt
codex	Hard-blocked (read-only sandbox) — see linked issue
zarvis	Prompted per edit (approve? edit_file)

Ask

Document a per-harness capability + default-approval matrix (write access, approval prompting, whether SetApprovalMode is honored, PTY/input support) in docs/harnesses.md, and consider converging on a consistent default where feasible.

Found during an isolated dogfood run building a browser game with claude/codex/zarvis.

[ded-furby]

I checked the current docs and adapter code, and the mismatch is real enough to document more explicitly.

What I found:

• docs/harnesses.md says approval flow is "native in zarvis; translated where CLI-backed harnesses expose enough control", but it doesn't call out the current per-harness/headless behavior.
• docs/unified-tool-layer.md says Claude Code and Codex get the same injected MCP tools when agentd-mcp is available, which reads like capability parity unless you already know the adapter differences.
• In code, headless Claude and Codex both ignore SetApprovalMode messages today:
  • crates/adapter-claude/src/main.rs: // headless claude doesn't gate tools; ignore.
  • crates/adapter-codex/src/main.rs: // headless codex doesn't gate tools; ignore.
• docs/zarvis.md is much more explicit: it documents safe vs risky tools and the approval/automode behavior in detail.

A small docs fix that would help would be a matrix in docs/harnesses.md (or a dedicated section) with rows like:

• interactive/headless support
• whether SetApprovalMode is honored
• whether risky writes are gated by agentd vs the upstream CLI
• whether MCP/unified tools are injected
• any known default constraints such as Codex headless being read-only by default upstream

That would make the current behavior predictable without implying that shared approvals/tools mean identical write semantics across harnesses.