[FEATURE] Only prompt workspace trust when configuration actually changes

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Problem

The workspace trust prompt appears every interactive session, even when .claude/settings.json, .claude/settings.local.json, and workspace directories haven't changed since the last acceptance.

This creates security theater rather than actual security:

1. Users develop muscle memory to reflexively hit "1" without reading
2. The one time something actually malicious changes, they'll bypass it by habit
3. Frequent, ignored prompts are worse than rare, meaningful ones

This is similar to the EULA problem: when everyone clicks "I agree" without reading, the agreement becomes meaningless while still creating a false sense of informed consent.

Current Behavior

⚠ This folder pre-approves 183 tool permissions in .claude/settings.json and
.claude/settings.local.json:
  WebFetch, WebSearch, Edit, Write, Bash, ...
⚠ This folder adds 1 directory to the workspace in .claude/settings.json:
  /Users/username
These will apply without asking. Only proceed if you trust this configuration.

❯ 1. Yes, I trust this folder
  2. No, exit

This appears every session for unchanged configurations. The prompt reads from /dev/tty (not stdin), so there's no automation workaround.

Why This Matters

Habituated bypassing is worse than no check at all. Security prompts should be rare enough that users actually read them. When a prompt appears every session for an unchanged config, it trains users to ignore it — which means the security check has negative value.

Rare, change-triggered prompts → users pay attention
Frequent, unchanged prompts → users develop reflexive bypass behavior

Proposed Solution

Track a hash or timestamp of the last-trusted configuration state and only re-prompt when:

1. First time opening this workspace, OR
2. Configuration changed: .claude/settings.json, .claude/settings.local.json, or workspace directories modified, OR
3. Periodic reconfirmation (optional): N days since last trust, if you want time-based expiry

Store the trust state keyed by workspace path + config hash.

Alternative Solutions

Workarounds Considered

• echo "1" | claude doesn't work (prompt reads from /dev/tty, not stdin)
• --print mode skips the dialog but isn't suitable for interactive use
• Reducing pre-approved permissions just makes the warning smaller, doesn't solve the repetition problem

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

This issue report was written with the assistance of Claude Sonnet 4.5, after we had gone through several iterations of trying to make the startup prompt go away.

Related Issues

• #73364 — concurrent sessions clobber hasTrustDialogAccepted
• #71562 — trust flag not persisting
• #72507 — pre-2.1.195 projects never re-fire trust dialog

These are all about trust state not saving correctly. This issue is different: trust state works, but the design of prompting every session defeats its security purpose.