[BUG] First launch with --permission-mode bypassPermissions leaves the workspace permanently untrusted (trust dialog never shown again)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

When I open a brand-new folder for the very first time with claude --permission-mode bypassPermissions, Claude Code registers the project in ~/.claude.json with hasCompletedProjectOnboarding: true but hasTrustDialogAccepted: false. Because onboarding is already marked complete, the workspace trust dialog is then never shown again on any subsequent interactive launch. The folder is stuck untrusted and there's no way to trust it from inside the product.

This went unnoticed until the trust hardening from GHSA-mmgp-wc2j-qcv7 / CVE-2026-33068 (fixed in 2.1.53) started enforcing trust on permissions.allow. Now, every plain claude launch in that folder ignores my allowlist and prints a warning telling me to "accept the trust dialog" — but the dialog never appears, so the instruction is impossible to follow.

I think the root cause is that the re-prompt is gated on hasCompletedProjectOnboarding rather than on hasTrustDialogAccepted. The two are effectively coupled into one gate, so a folder can be "onboarded" yet untrusted, and the trust dialog (part of the one-time onboarding flow) can never run again. Suppressing the dialog during the bypassPermissions launch itself is fine; the problem is there's no later recovery path.

What Should Happen?

On an interactive launch, if hasTrustDialogAccepted is false, Claude Code should show the workspace trust dialog even when hasCompletedProjectOnboarding is true. The trust gate and the onboarding gate should be independent, so a folder first opened with --permission-mode bypassPermissions can still be trusted through the normal flow.

Error Messages/Logs

Ignoring 159 permissions.allow entries from .claude/settings.local.json: this workspace has not been trusted. Run Claude Code interactively here once and accept the trust dialog, or set projects["C:/Users/<user>/.../update_things"].hasTrustDialogAccepted: true in C:\Users\<user>\.claude.json.

Steps to Reproduce

1. Pick a folder Claude Code has never opened (no entry for it in ~/.claude.json). Add a .claude/settings.local.json containing some permissions.allow entries.
2. For the very first launch in that folder, run:

``
claude --permission-mode bypassPermissions
``
Then exit.

1. Inspect ~/.claude.json — the new project entry has hasCompletedProjectOnboarding: true and hasTrustDialogAccepted: false:

``json
{
"hasTrustDialogAccepted": false,
"hasCompletedProjectOnboarding": true,
"hasClaudeMdExternalIncludesApproved": false,
"history": [],
"exampleFiles": []
}
``

1. Relaunch with a plain claude (on 2.1.53+).

• Expected: the trust dialog appears so I can accept it.
• Actual: no dialog ever appears; the "Ignoring N permissions.allow entries … not trusted" warning prints and my allowlist is dropped on every launch.

The only workaround is to manually set projects["<path>"].hasTrustDialogAccepted: true in ~/.claude.json (or use a SessionStart hook to set it). There is no UI-driven fix.

Claude Model

Not sure / Multiple models (this is a startup/trust issue and isn't model-dependent)

Is this a regression?

Yes, this worked in a previous version. Before the trust hardening, an untrusted folder's permissions.allow entries were still honored, so this limbo state was harmless and invisible. The CVE-2026-33068 fix (2.1.53) now enforces trust, which surfaces the unrecoverable-untrusted state.

Last Working Version

2.1.52 (last version before the trust enforcement landed in 2.1.53)

Claude Code Version

2.1.197 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other (Git Bash / MINGW64 on Windows)

Additional Information

Related issues/advisories:

• Security advisory GHSA-mmgp-wc2j-qcv7 / CVE-2026-33068 — the trust hardening that exposed this.
• #36403 — trust acceptance not persisted; same hasTrustDialogAccepted: false + hasCompletedProjectOnboarding: true signature, but there the dialog is shown and just fails to stick (closed as duplicate). This report is the related-but-distinct case where the dialog is never shown at all.
• #9113, #43958 — adjacent trust-persistence / recognition issues.