coilyco-flight-deck/ward

Fork 0

Linux-only sandbox jail vs macOS/Windows depth-0 enforcement is disclosed only in SECURITY.md fine print; README and exec-verb.md never platform-qualify the gate #483

New issue

Closed

opened 2026-07-01 22:54:01 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-01 22:54:01 +00:00

Member

Why

Persona security-skeptic / angle front-page. SECURITY.md's "What counts as a vulnerability" fine print discloses, in the middle of a scoping bullet:

The jail is Linux-only — on macOS/Windows enforcement is depth-0 (the harness allowlist) and descendant bypass is a known limitation, not a vulnerability

That is a materially different guarantee per platform: on Linux the wrapper "holds at arbitrary process depth"; on macOS — the platform the README's brew-first install path predominantly serves — a child process spawned by a gated verb escapes the gate by design.

Where else is this stated? Nowhere. docs/exec-verb.md (the gate's own doc) contains zero occurrences of linux/macos/sandbox/jail/depth; the README's "What it does" promises argv validation, audit row, and clean-tree gate with no platform caveat. A macOS adopter who does not happen to read the vulnerability-scoping bullet believes they get the same containment Linux gets.

The skeptic's read: the strongest enforcement property the project claims (depth-N holding) is quietly conditional, and the condition excludes the primary install audience. Honest fine print in the wrong place is indistinguishable from burying the caveat.

Deliverable

State the platform asymmetry where the guarantee is made: one sentence in README "What it does" (or a platform-support note it links) and a short section in docs/exec-verb.md — Linux: cli-guard sandbox jail, depth-N; macOS/Windows: depth-0 allowlist, descendant bypass possible.

Done condition

A macOS reader learns the depth-0 limitation from the README or exec-verb.md (not only from SECURITY.md's vuln-scoping), and the claim language ("holds at arbitrary process depth") is platform-qualified everywhere it appears.

Severity: major-friction · persona: security-skeptic · angle: front-page
Filed by Claude Code during a cold-read release pressure test (run 34).

## Why Persona `security-skeptic` / angle `front-page`. SECURITY.md's "What counts as a vulnerability" fine print discloses, in the middle of a scoping bullet: > The jail is Linux-only — on macOS/Windows enforcement is depth-0 (the harness allowlist) and descendant bypass is a known limitation, not a vulnerability That is a materially different guarantee per platform: on Linux the wrapper "holds at arbitrary process depth"; on macOS — the platform the README's brew-first install path predominantly serves — a child process spawned by a gated verb escapes the gate by design. Where else is this stated? Nowhere. `docs/exec-verb.md` (the gate's own doc) contains zero occurrences of linux/macos/sandbox/jail/depth; the README's "What it does" promises argv validation, audit row, and clean-tree gate with no platform caveat. A macOS adopter who does not happen to read the vulnerability-scoping bullet believes they get the same containment Linux gets. The skeptic's read: the strongest enforcement property the project claims (depth-N holding) is quietly conditional, and the condition excludes the primary install audience. Honest fine print in the wrong place is indistinguishable from burying the caveat. ## Deliverable State the platform asymmetry where the guarantee is made: one sentence in README "What it does" (or a platform-support note it links) and a short section in `docs/exec-verb.md` — Linux: cli-guard sandbox jail, depth-N; macOS/Windows: depth-0 allowlist, descendant bypass possible. ## Done condition A macOS reader learns the depth-0 limitation from the README or exec-verb.md (not only from SECURITY.md's vuln-scoping), and the claim language ("holds at arbitrary process depth") is platform-qualified everywhere it appears. --- **Severity: major-friction** · persona: security-skeptic · angle: front-page Filed by Claude Code during a cold-read release pressure test (run 34).

coilyco-ops added the

pressure-test

label

2026-07-01 22:54:01 +00:00

coilyco-ops referenced this issue

2026-07-01 22:54:42 +00:00

meta: release pressure-test run log (cold-read usability sweeps) #428

coilyco-ops added this to the ward launch milestone

2026-07-01 23:29:22 +00:00

coilyco-ops added the

headless

labels

2026-07-01 23:30:19 +00:00

coilyco-ops referenced this issue

2026-07-01 23:58:52 +00:00

SECURITY.md's vulnerability scope never mentions the ward agent/container/credential surface at all #451

coilyco-ops referenced this issue

2026-07-02 00:01:42 +00:00

meta: jul 1st evening sprint - launch burndown session 1 #492

coilyco-ops commented

2026-07-02 02:58:12 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-483 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T02:58:09Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-483` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T02:58:09Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-02 03:00:07 +00:00

docs(security): platform-qualify the exec-gate depth guarantee

coilysiren closed this issue

2026-07-02 03:00:07 +00:00

coilysiren commented

2026-07-02 03:00:39 +00:00

Owner

WARD-OUTCOME: done - platform-qualified the exec-gate depth guarantee in README "What it does" and a new "Enforcement depth by platform" section in docs/exec-verb.md.

Small, contained doc change - the kind that's easy to under-scope. The temptation was to drop one sentence in the README and call it, but the done-condition was explicit that the depth-N claim be qualified everywhere it appears, so I traced "holds at arbitrary process depth" across the tree first. Turned out SECURITY.md already carried the caveat correctly (its fine print was the whole complaint), so the fix was moving the disclosure to where the guarantee is made - the front-page "What it does" and the gate's own doc - not rewriting the security policy.

What fought back a little: nothing technical, but getting the framing right mattered. I leaned into naming macOS/Windows as the brew-first audience that predominantly hits this, since burying-the-caveat was the skeptic's actual read. Confident in the result - it's prose-only, pre-commit (dead-cross-links, catalog-trifecta, layout) is green, and the merge from main only pulled unrelated Go changes.

One rough edge worth a possible follow-up: this documents the depth-0 asymmetry but doesn't narrow it - macOS/Windows descendant containment is still a design gap, not just an undocumented one. If that ever feels worth closing rather than disclosing, it'd be a real feature issue, not a docs one.

WARD-OUTCOME: done - platform-qualified the exec-gate depth guarantee in README "What it does" and a new "Enforcement depth by platform" section in docs/exec-verb.md. Small, contained doc change - the kind that's easy to under-scope. The temptation was to drop one sentence in the README and call it, but the done-condition was explicit that the depth-N claim be qualified *everywhere* it appears, so I traced "holds at arbitrary process depth" across the tree first. Turned out SECURITY.md already carried the caveat correctly (its fine print was the whole complaint), so the fix was moving the disclosure to where the guarantee is *made* - the front-page "What it does" and the gate's own doc - not rewriting the security policy. What fought back a little: nothing technical, but getting the framing right mattered. I leaned into naming macOS/Windows as the brew-first audience that predominantly hits this, since burying-the-caveat was the skeptic's actual read. Confident in the result - it's prose-only, pre-commit (dead-cross-links, catalog-trifecta, layout) is green, and the merge from main only pulled unrelated Go changes. One rough edge worth a possible follow-up: this documents the depth-0 asymmetry but doesn't *narrow* it - macOS/Windows descendant containment is still a design gap, not just an undocumented one. If that ever feels worth closing rather than disclosing, it'd be a real feature issue, not a docs one.

coilysiren referenced this issue

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283