Headless git allow-list has no cwd scoping — combines with peer-path tool into an unenforced cross-workspace write gap

[Deathrage]

Symptom

HEADLESS_ALLOWED_TOOLS in src/workspaces/adapters/claude.ts (added in
5c331f54, narrowed in fa4d8ea5) allow-lists Bash(git add:*) and
Bash(git commit -m:*) for headless Claude Code runs, scoped to unblock a
run's own report commits. These are pure command-prefix rules — nothing
ties them to the run's own workspace directory (ws.dir).

Separately, alice-workspace peer path --id <wsId> (introduced in
8405b9c, already on the same headless allow-list via
Bash(alice-workspace:*)) hands an agent a peer workspace's absolute
directory specifically so its native tools — including native git —
can act on it. That commit's own message states the boundary is
intentionally not code-enforced: "Collaboration discipline lives in
prose (skill + instruction + persona), not machinery... an
autonomous/headless run reads peers but writes only its own workspace."

Combining the two: a headless run today can resolve a peer's absolute
path, then cd <peer-dir> && git commit -m ... (or git -C <peer-dir> commit -m ...), and the Bash allow-rule still matches — there is no
code path that rejects it. Before this session's fix, git add/git commit were denied headlessly in any cwd, which was over-restrictive
but incidentally closed this specific risk dimension; that incidental
protection is gone now that git commits are allowed at all headlessly.

Two independent code-review rounds during the 2026-08-11 handoff-defect
fix flagged this; it was deliberately left undone in that PR as an
out-of-scope architectural question rather than "fixed," and a source
comment was corrected to stop overclaiming containment that doesn't
actually exist in code.

Suspected files / subsystem

• src/workspaces/adapters/claude.ts — HEADLESS_ALLOWED_TOOLS (no cwd
  scoping on any Bash allow-rule, not just the new git ones)
• src/tool/workspace-path.ts — peer path resolution
• Workspace Manager permission model generally; see
  docs/workspace-agent-guidance.md and
  docs/workspace-issues-and-scheduling.md ("writes stay local" policy)

Why deferred

A real fix means giving native Bash/git calls actual cwd/path
enforcement across all four CLI adapters (claude/codex/opencode/pi) —
a materially larger architecture change than a two-defect hotfix PR
should absorb. Containment today rests entirely on unenforced
agent-instruction discipline (skill/persona prose), which is the
project's existing, deliberate design choice per 8405b9c, not a new
gap introduced here — this session's change just removed one incidental
mitigation (git being denied outright) for one specific write type.

Related

• 8405b9c — introduced alice-workspace peer path + the
  prose-not-machinery design decision
• 5c331f54, fa4d8ea5 — this session's fix that added git to the headless
  allow-list, prompting the finding
• handoff/2026-08-11_openalice-fixes.md on the live deployment (not in
  this git repo) — the original defect report that motivated the change

[RainMona]

Community triage (current dev, Aug 2026)

Status: still-open as an architecture item; specific vector may be narrower now

On current dev, HEADLESS_ALLOWED_TOOLS in the Claude adapter lists OpenAlice CLIs (alice:*, alice-workspace:*, …) and does not currently include the Bash(git …) allow-rules described in the report — so the exact headless-git + peer path write path may no longer be reachable by default.

What remains true:

• Bash allow-rules are still prefix-shaped, without ws.dir / cwd enforcement.
• Cross-workspace write discipline via peer path is still largely instruction / skill governed, not a hard gateway deny.

Ask for maintainers: Is headless git intentionally disallowed again, and is cwd-scoped enforcement on the roadmap?
Ask for reporter: If you still have a build that allows headless git, can you confirm whether a cross-workspace commit via peer path remains possible on latest dev?

— triage note