[BUG] 2.1.232 nested-repo trust change silently disables statusLine (and other trust-gated features) — no re-prompt, no indicator for previously-inherited-trust repos

Status Closed — not planned
Reported on v2.1.232
Maintainer reply None cached
Activity 3 comments · opened Aug 15, 2026 · closed Aug 22, 2026

Environment

  • Claude Code 2.1.232 (native build), macOS (Darwin 25.5.0), Terminal.app
  • statusLine configured in ~/.claude/settings.json (ccstatusline), defaultMode: auto

Summary

2.1.232 changed nested-git-repo trust ("Fixed nested git repositories inheriting trust from a parent directory; each repository now requires its own trust confirmation"). The change itself is reasonable, but the migration is a silent regression:

  1. Repos that previously ran on inherited trust have hasTrustDialogAccepted: false in ~/.claude.json — the trust dialog was never shown for them (inheritance suppressed it), so the flag stayed at its default.
  2. After updating to 2.1.232, these repos become untrusted by their own flag, but the trust dialog is not re-shown when starting a session there. There is no prompt, no warning, no indicator.
  3. Trust-gated features silently stop working in exactly those folders. The most visible casualty is the custom statusLine command (gated on workspace trust since 2.1.51): the status line row just renders empty. The command is never spawned at all (verified with a logging wrapper — zero invocations), while running it manually from the same cwd works fine.

From the user's point of view: "my status line disappeared, but only in this one folder" — with config intact, the command healthy, and no error anywhere. It cost a long bisection (settings layers, env, versions, RC, repo content) before correlating with hasTrustDialogAccepted across folders.

Scale of impact

In my ~/.claude.json, the set of trusted project entries has been effectively frozen since inheritance started suppressing the dialog: dozens of true entries all date from before mid-June, and every project first opened after that has false (114 git repos under one parent folder in my case). All of them lost their custom status line at once upon updating to 2.1.232.

Expected

Either of:

  • Re-show the trust dialog on first session start in a nested git repo whose trust was previously inherited (i.e., treat "entry exists but never explicitly accepted" as "ask now"), or
  • At minimum, show an explicit indicator/notice when a configured statusLine (or other trust-gated feature) is being suppressed due to workspace trust, instead of rendering an empty row.

Actual

Session starts normally, no dialog, no notice; statusLine command is never executed; status line is silently empty. Flag can only be fixed by hand-editing ~/.claude.json.

Repro

  1. On a pre-2.1.232 version, trust a parent folder (e.g. ~/Projects), then open sessions in a git repo nested under it — dialog is skipped, projects["<repo>"].hasTrustDialogAccepted stays false, statusline works.
  2. Update to 2.1.232, start a new session in that repo: no trust dialog, empty status line.
  3. Set hasTrustDialogAccepted: true for that path and start a new session: status line is back.

Related: #23109 (trust prompt ergonomics for worktrees).

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗