[SaulBuilds]

HGW Week 1, runtime, 5 of 5. Stack: #79 → #80 → #81 → #82 → this PR (base hgw/w1-loop-capability). Green on its own. Refs #77 (HGW-W11). Owner decision 2026-10-15, HGW (3) (D-16 as amended). The command list needs owner confirmation before merge.

What changes

The list is data: agent-sidecar/policy/auto_approve.toml, compiled in.

• CITRATE_HERMES_AUTO_APPROVE=0 turns it off; an absolute path replaces it.
• Each rule is an argv template: program, subcommands, allowed flags, value flags with kinds, required flags, operand kind, count and allowed values. -- is never allowed.

Shipped list:

• ls, pwd, cat, head, tail, wc (relative paths only)
• node <relative file>
• npm run build|test|lint|typecheck, npm test, npx tsc --noEmit
• forge build|test (no --ffi)
• cargo build|test|check with --offline or --frozen
• git init, git status, git diff, git add <relative paths>, git commit -m

When a listed command runs without a card (all must hold):

• the session is untainted;
• the OS sandbox is enforced;
• the folder is inside a project root (feat(sidecar,shell): project write policy, git in the sandbox (v0.5.1 HGW-W2) #80, feat(sidecar): project_create, HIC-approved (v0.5.1 HGW-W3, runtime half) #81), and the run may write only that project, not the wider grant.

Anything unlisted, network-capable or outside a project asks, as before. After taint every command asks (#79). With no sandbox (Windows), nothing is auto-approved.

Records and results:

• Each auto run is recorded write-ahead (shell.run.auto, actor agent, HIC-2). If it cannot be recorded, it asks instead.
• Results carry run.approval = {mode: "auto", rule, project}; card runs carry {mode: "member"}.

agent-loop: ToolOutcome::Vouched. An auto run's output comes from the project's own files: no network, writes only in the project, untainted session. Like a folder-grant file read, it does not taint. The worker wire maps it to Ok, which fails closed across the process boundary.

git through shell_run:

• commits as Hermes <hermes@citrate.invalid>: the scratch HOME has no identity, so git refused to commit;
• always runs with core.hooksPath=/dev/null and core.fsmonitor=false as command-scope config ([v0.5.1 HGW-W11] Auto-approve safe-command list (amended D-16) #77).

Other:

• GET /shell/auto-approve returns {enabled, conditions, rules} for the app's Settings ([v0.5.1 HGW-W11] Auto-approve safe-command list (amended D-16) #77, "Settings shows the list").
• shell_run's description states the approval rules and says to ask, not retry, after a decline.

End to end (e2e_build_tests; real Seatbelt, scratch home, scripted model, real node, npm and git)

1. Create the project with project_create (the only card).
2. Write package.json, build.js and a source file with a bug.
3. git init, git add, git commit.
4. npm run build fails. The model reads ReferenceError: greeet is not defined from the tool result and fixes it with fs_edit.
5. The build passes; commit again.
6. An unlisted command, approved on a card, brings in untrusted output. The next listed command (git status) then asks, with the taint reason on its card.

Negative checks in the same run:

• the build cannot write outside its project;
• it cannot reach a local listener (no network);
• no risky git state is left behind;
• nothing outside the grants changes.

On Linux the same tests run under bwrap. They skip without a working bwrap unless CITRATE_REQUIRE_BWRAP=1.

Interface for the core lane

• No new cards. The Activity monitor should label run.approval.mode == "auto" runs, showing the rule and project.
• Settings reads GET /shell/auto-approve.

Needs a decision

1. Confirm the command list (D-16 as amended). Two choices are mine: git init (needed so that later commands are not tainted by a carded git init) and node <file>. forge/cargo without --offline: forge is allowed without --offline because the sandbox already blocks the network, while cargo must pass --offline or --frozen.
2. The commit identity Hermes <hermes@citrate.invalid> overrides the repo's user.name/user.email for Hermes's git runs. Is that wording and policy right?
3. Is Vouched right? It treats auto-run output as trusted, consistent with the 2026-10-01 decision that folder-grant reads are trusted.

Tests (red first)

• auto_approve unit: +4. Covers the accept and refuse matrix (including the network cases, git -c, --ffi, unlisted npm scripts, --, absolute and .. paths), list validation, and the environment switch.
• auto_approve_tests: +8. Real sandbox: no card for listed commands; asks off the list or outside a project; taint blocks auto; no sandbox means no auto; project-only writes; switch off; recorded; list route.
• e2e_build_tests: +1.
• taint_tests vouched: +1.
• shell_run: git identity +1, hooks and fsmonitor off +1.
• Workspace: 2288 → 2304 passed, 0 failed.

🤖 Generated with Claude Code

https://claude.ai/code/session_018wWZZ8GRVU9USh3kKQHsFe

[BerryManifold]

Holding auto-approval pending resolution of the blocking git-state security boundary issue confirmed in the #84 follow-up. The owner-approved command-list scope is understood; the blocker concerns enforcement around command effects. Reproduction details are retained privately under the organization security policy. Please complete the safeguard and add regression coverage before enabling this path.

[BerryManifold]

Approval submitted at the owner’s explicit direction. This does not retract or resolve the previously reported git-state cleanup finding; no new verification of a fix is claimed.

[Matr0xshka]

Approval submitted at the owner’s explicit direction. This does not retract or resolve the previously reported git-state cleanup finding; no new verification of a fix is claimed.

[SaulBuilds]

Landed in main via #84 (squash 75e21cd), per the owner's 2026-10-15 decision to land the HGW stack #80–#84 as one squash. Reviewed and approved here.