`hasTrustDialogAccepted: false` coexists with fully-working hooks in 2.1.241 — no reliable programmatic signal for workspace trust

Environment: Claude Code 2.1.241, Linux.

What I expected: hasTrustDialogAccepted in .claude.json to reflect whether a workspace is trusted, since hooks (and other gated features) require workspace trust.

What happens: I maintain Agent Console, a desktop console that drives Claude Code and needs to know whether a project is trusted before offering hook-dependent features (otherwise they fail silently — the failure mode described in the docs). Empirically, in 2.1.241 a project can have hasTrustDialogAccepted: false while its hooks execute normally. The field no longer encodes trust, and I can't find any field that does.

Why it matters: trust gates hooks silently. Tools that integrate Claude Code (IDE wrappers, consoles, schedulers) need a stable way to answer "will hooks run here?" before the user hits a dead feature. Related reports of the same underlying gap from other angles: #79737 (scheduled task claims folder not trusted while hasTrustDialogAccepted: true — the inverse of my case), #86857 (trust dialog never prompts, gated features silently disabled), #88418 (trust state split across path spellings).

Ask: either (a) document a stable field/exit-code that reflects effective workspace trust, or (b) add it to claude auth status / a claude trust status subcommand. Happy to test a canary build against my integration.