[BUG] Skills-dir plugins don't load in subfolders of a trusted directory — every launch dir silently gets hasTrustDialogAccepted:false, no dialog ever shows (Linux, no git)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

We ship a set of skills as project-scope plugins (folders with .claude-plugin/plugin.json under .claude/skills/). On v2.1.233, Debian 13, interactive CLI, this is what I get:

1. Start claude in a project directory that has .claude/skills/ plugins. No trust dialog shows up. ~/.claude.json gets a new entry projects["<dir>"].hasTrustDialogAccepted: false and the plugins are not loaded. /plugin → Errors: "N project-scope plugin directories under ./.claude/skills/ were not loaded because this workspace was not trusted when plugins were scanned."

1. Flip that entry to true by hand (the workaround documented at https://code.claude.com/docs/en/permissions). Now the plugins load fine — but only when starting from that exact directory.

1. mkdir any subfolder inside that trusted directory, start claude there. Plugins are gone again, and ~/.claude.json gains another entry for the subfolder, again false, again without ever asking.

So every directory I ever launch from ends up with a permanently-untrusted entry and there is no interactive way out — the dialog never comes. Hand-editing ~/.claude.json is the only fix (we scripted it in the end, flipping false entries under the workspace root, which feels very wrong to have to do).

Possibly relevant: there is no git anywhere in this tree — everything is SVN working copies (.svn, no .git). #72896 was closed as fixed on v2.1.233 with a repro on macOS using plain/git folders, and that's exactly the version I'm on — but I still hit the silent-false-without-dialog behavior on Linux in an svn-only tree. If workspace/repo detection is git-based, every directory here is its own workspace, which would explain the per-directory entries.

Also worth noting: the security page (https://code.claude.com/docs/en/security#additional-safeguards) says trust acceptance is "saved per directory", and the permissions page tells users to hand-edit ~/.claude.json when no dialog is offered. So the per-directory part seems intended — but recording false for a directory the user was never asked about, and then gating on it, can't be.

What Should Happen?

Either the subfolder inherits the parent's trust, or the trust dialog appears there once. Anything except silently writing false for a directory nobody was asked about.

Steps to Reproduce

mkdir demo && cd demo
mkdir -p .claude/skills/hello/.claude-plugin .claude/skills/hello/commands
echo '{"name":"hello","description":"demo","version":"0.0.1"}' > .claude/skills/hello/.claude-plugin/plugin.json
printf -- '---\ndescription: hi\n---\nSay hi\n' > .claude/skills/hello/commands/hi.md
claude   # interactive; note: no trust dialog; /plugin shows hello not loaded; ~/.claude.json now has this dir with hasTrustDialogAccepted:false

Then:

# flip projects[".../demo"].hasTrustDialogAccepted to true by hand, relaunch claude in demo
# hello loads fine now (/plugin, /hello:hi)

mkdir sub && cd sub && claude
# plugins gone again, no dialog, ~/.claude.json gains .../demo/sub with false

Error Messages/Logs

From /plugin → Errors (step 1):

1 project-scope plugin directories under ./.claude/skills/ were not loaded because this workspace was not trusted when plugins were scanned. After accepting the trust dialog, run /reload-plugins (or relaunch) to load them.

(There was no trust dialog to accept.)

Environment

Claude Code 2.1.233, Debian 13, zsh, interactive CLI sessions, SVN working copies only (no .git anywhere in the tree).

Cross-referencing: #72896 (closed as fixed, but the silent false entry still happens here), #65864 (I left a longer data point there before realizing it was already closed).