Ship PR #896 (directory-scoped shell approvals) — users are still getting prompted for subdirectories

[Aaronontheweb]

Symptom

Real user reports: "I approve a shell command rooted at a parent directory, and the next invocation in a subdirectory re-prompts as if I never approved it." Repeatable in any session that runs find <dir>, ls <dir>, or similar across nested paths — every distinct path gets its own prompt and its own persisted entry.

Cause

PR #896 (cd69e4d2, directory-scoped shell command approval patterns) was merged into dev but has not been included in any released daemon binary. The current released daemon is 0.17.2 (commit 96ba080, 2026-05-06), which was cut before #896 landed.

The pre-#896 verb-chain extractor stores patterns shaped like find <first-positional-path> (verb plus non-flag tokens, no path normalization, no directory-root scoping). Two real consequences:

1. Sub-path re-prompts. Approve find ~/repo/foo. Next call is find ~/repo/foo/bar -type f → extracts a different verb chain (find ~/repo/foo/bar) → exact-match fails → re-prompt.
2. tool-approvals.json accumulates one entry per distinct path the user touches, even within a single trusted parent.

PR #896's ExtractApprovalEntries was specifically designed to fix this: it stores <absolute-root>/ (e.g., /home/user/repo/foo/) and matches subsequent invocations via IsWithinRoot. The fix is sitting on dev; users aren't getting it.

What's pending in dev past 0.17.2

Beyond #896, dev also contains:

• chore: replace hand-rolled TimeProvider subclasses with FakeTimeProvider #898 — replace hand-rolled TimeProvider subclasses (test infra)
• fix(security): reject non-loopback Daemon.Host in Local exposure mode #901 — reject non-loopback Daemon.Host in Local exposure mode (security fix)
• chore: remove unused DocFX dependency #904 — remove unused DocFX dep
• fix: wizard init with Personal posture silently disables all features #907 — wizard with Personal posture silently disables all features (real wizard bug)
• TUI chat status bar shows fallback 32K context window instead of daemon-detected value #906/fix: use daemon-reported context window in TUI status bar (#906) #913 — TUI status bar uses daemon-reported context window
• feat: harden SearXNG backend (UA, 429 retry, timeout, 403 detection) #914 — SearXNG hardening
• refactor: extract shared FakeHttpClientFactory and remove duplicated JsonResponse helpers #917 — test refactor
• fix(logging): route session diagnostics into one session log #916 — single-file session diagnostics
• docs(openspec): archive directory-scoped approvals + document symlink defense (closes #922) #923 — symlink defense doc + archive

That's a substantial backlog of fixes accumulating without a release vehicle.

Action

1. Cut 0.17.3 from dev ASAP to ship feat: directory-scoped shell command approval patterns #896 + the other accumulated fixes. The pain reported here will keep recurring on every pre-feat: directory-scoped shell command approval patterns #896 daemon for as long as the release lag persists.
2. Migration: existing users have tool-approvals.json entries shaped like the pre-feat: directory-scoped shell command approval patterns #896 verb-chain format (e.g., find ~/repo/foo). After upgrading to a feat: directory-scoped shell command approval patterns #896-bearing daemon, those entries:
   • Won't be recognized as directory roots (no leading /, has a verb prefix).
   • Will continue to be matched as exact verb chains, which means the upgrade does not retroactively fix existing approvals — only NEW "Approve always" decisions will store directory roots.
   • The user has to re-approve once per parent directory to get the directory-root grandfathering behavior.
   • Recommendation: ship a short upgrade note in the 0.17.3 release notes explaining this. The new netclaw approvals CLI (PR feat: netclaw approvals CLI (list / revoke / TUI) (closes #921) #927) lets users inspect and clean up the stale verb-chain entries.

Suggested follow-up (optional, not blocking)

• A one-shot migration that detects pre-feat: directory-scoped shell command approval patterns #896-style entries (entries containing ~/ or starting with a verb-and-space pattern) and surfaces them via netclaw doctor so users know they should re-approve.
• A netclaw approvals migrate subcommand that prompts the user to either keep or revoke each stale entry. Cheap to add given feat: netclaw approvals CLI (list / revoke / TUI) (closes #921) #927 already wires the CLI surface.

Acceptance for THIS issue

• A 0.17.3 (or equivalent) release published with PR feat: directory-scoped shell command approval patterns #896 in it.
• Release notes call out the migration nuance for existing tool-approvals.json files.

Related

• PR feat: directory-scoped shell command approval patterns #896 — the fix that's stuck on dev.
• PR feat: netclaw approvals CLI (list / revoke / TUI) (closes #921) #927 — netclaw approvals CLI (gives users the tool to clean up stale entries after upgrade).
• Issue FilePathApprovalMatcher.IsApproved uses OrdinalIgnoreCase unconditionally (POSIX case-collision hazard) #928 — FilePathApprovalMatcher.IsApproved POSIX comparer hazard (separate, but adjacent to the comparer-consolidation work in feat: netclaw approvals CLI (list / revoke / TUI) (closes #921) #927).