[FEATURE] Re-verify risk when a previously-trusted path's action-type escalates

Summary

Once a directory/path is approved for one kind of action (e.g. reads), that trust currently persists even when a later action against the same path is a materially different, higher-risk kind (e.g. a destructive write/delete). Please re-prompt when the risk category of the requested action escalates, rather than trusting a path indefinitely based on its first approval.

Current behavior

Permission approval today is scoped primarily to path/tool combinations. Once granted, it doesn't appear to be re-evaluated based on what kind of operation is actually being requested against that path later in the same or a future session — a folder trusted for read access doesn't get a fresh check when a subsequent request against it is destructive (delete, overwrite, force-push) rather than read-only.

Motivation

This is a documented failure pattern across the broader AI-coding-agent market, not unique to any one tool: independent security research (Mindgard, "Persistent Trust Flaws in AI Coding Agents") describes exactly this as "approve once, exploit forever" — trust attaches to the path rather than to the actual risk of the action being taken against it, so risk can silently escalate under an approval the user gave for something much safer. Several existing Claude Code bug reports (e.g. destructive git reset --hard runs, unauthorized destructive changes despite explicit rules) are consistent symptoms of the same underlying gap — the permission model not distinguishing action risk tiers within an already-trusted path.

Proposed behavior

1. Classify requested actions by risk tier (read < write < destructive/irreversible), independent of path.
2. When an action against a previously-approved path crosses into a higher risk tier than what was originally approved, re-prompt for that specific tier — don't silently extend the original approval to cover it.
3. Let the re-prompt be sticky per (path, risk-tier) pair, so this doesn't degrade into repeated prompts for the same class of action once approved at that tier.

Why it matters

• Closes a real, independently-documented trust-model gap rather than a hypothetical one — this is the exact mechanism behind some of the most severe agent incidents reported across the market (e.g. an agent deleting a production database under an approval originally granted for far less risky operations).
• Keeps the convenience of not re-prompting for routine, already-approved-risk-tier actions, while still gating the moments that actually matter.

Related issues (adjacent, not duplicates)

• #64227 Claude Code repeatedly made unauthorized destructive changes, ignored explicit rules, and permanently destroyed user data across multiple sessions — a symptom consistent with this gap, framed as a model-behavior bug rather than a permission-model design proposal.
• #34327 Claude Code destroyed user's uncommitted work by running git reset --hard on session startup — TWICE (closed) — same category of symptom.
• #53610 [Feature] Multi-agent runtime needs mechanical enforcement: 9 gaps that defeat unattended overnight operation (closed/stale) — broader unattended-reliability meta-issue; this request is narrower and specific to the trust/risk-escalation mechanism.

Notes

• Reviewed for duplicates before filing (multiple search passes: "trust escalation directory approval read then write destructive", "once approved always trusted permission scope creep", "re-verify risk when a previously-trusted path's action-type changes") — nothing found proposing this specific mechanism as of 2026-07-19.
• Sourced from market research, not from a personal incident: Mindgard, "Persistent Trust Flaws in AI Coding Agents" (approve-once-exploit-forever pattern), cross-referenced against existing Claude Code data-loss bug reports as supporting evidence that the same failure mode occurs here too.