Workspace trust dialog fails to prompt on launch, silently disabling gated features (e.g. statusLine)

Description

The workspace trust dialog did not appear for some project folders in our testing, even across repeated fresh launches and in multiple terminal apps. The folder stayed stuck with hasTrustDialogAccepted: false in ~/.claude.json, and trust-gated features (confirmed: the custom statusLine) stayed silently disabled with no error, no prompt, no indication anything was wrong. We did not capture a claude --debug log during the failure, so we can't confirm whether the trust check silently fails, is skipped by another code path, or something else — this report documents the symptom, not the root cause.

This is a variant of the trust-gating behavior confirmed in #35974 (custom status line showing nothing when workspace trust blocks it) — but here the underlying trust dialog itself never fires, so there's no way to clear the block through the normal UI at all.

Steps to reproduce

1. Identify a project folder whose entry in ~/.claude.json is either completely missing or has "hasTrustDialogAccepted": false, and has a working statusLine command configured in settings.json.
2. Fully quit Claude Code (not /clear — a new process) and run claude fresh in that folder.
3. Observe: no "Do you trust the files in this folder?" prompt appears at startup, in either of two different terminal apps tested (cmux/Ghostty-based, and iTerm2).
4. The custom statusline never renders. No error is shown anywhere in the session.
5. Manually editing ~/.claude.json to set "hasTrustDialogAccepted": true for that exact path fixes the statusline immediately, in the already-running session, with no restart needed — confirming trust gating, not the statusline feature itself, is the actual blocker, and that the gate is checked live/continuously rather than only once at process startup. That narrows the bug specifically to the dialog never firing, not to a stale one-time check.

All affected folders in our case were pre-existing (visited under earlier Claude Code versions) rather than brand-new folders created fresh after upgrading to 2.1.233 — we did not test whether a truly new folder on this version reproduces the same missing-dialog behavior.

Expected behavior

Either the trust dialog should reliably appear on first run in a new/untrusted folder, or trust-gated features that get silently disabled (like statusLine) should surface some indication (a warning line, a doctor check, anything) that the folder isn't trusted — instead of failing completely silently.

Additional finding: trust does not inherit across subdirectories

Trust is tracked per exact path in ~/.claude.json, not hierarchically. A parent folder being trusted (true) does not propagate to its subfolders — each subfolder gets its own independent entry and can be stuck false even when the parent above it is true. This compounds the dialog-not-firing bug: every new subdirectory a user works in (e.g. a new git worktree, a new nested project) needs its own trust prompt, and if that prompt doesn't fire, that subfolder silently loses trust-gated functionality too.

Environment

• Claude Code version: 2.1.233
• OS: macOS 26.5.2 (build 25F84), Apple Silicon
• Install method: native (~/.local/bin/claude → ~/.local/share/claude/versions/2.1.233)
• Terminals tested: cmux (Ghostty-based) and iTerm2 — same result in both, so not terminal-specific
• claude doctor was not able to help diagnose this, since it explicitly reads settings without triggering a trust prompt

Workaround

Manually set "hasTrustDialogAccepted": true under the affected path's entry in projects in ~/.claude.json, then restart Claude Code in that folder.