Workspace trust dialog shows a fraction of the pre-approved permissions and offers no way to review them

Summary

Since 2.1.232 removed trust inheritance from parent directories, every repository asks for its own trust
confirmation. That change is correct. But it exposed a gap in the dialog it now shows far more often: the
dialog asks me to accept a set of pre-approved permissions while showing me only a fraction of them, with
no way to expand the list, and no option other than accept everything or quit.

In practice the prompt asks for informed consent while withholding most of the information.

What the dialog looks like

⚠ This folder pre-approves 35 tool permissions in .claude/settings.local.json:
  Bash(pdftotext -layout "<file-1>.pdf" -), Bash(pdftotext -layout "<file-2>.pdf" -),
  Bash(apt list *), Bash(dpkg -l), Bash(sudo -n apt-get install -y poppler-utils),
  Bash(pdftotext -layout "<file-3>.pd…, and 26 more
  These will apply without asking. Only proceed if you trust this configuration.

❯ 1. Yes, I trust this folder
  2. No, exit

8 of 35 shown (~23%). The rest is summarised as "and 26 more". Entries are also truncated mid-string.
One of the eight visible entries is sudo -n apt-get install, so the 26 hidden ones cannot be assumed
harmless.

The three gaps

1. The list is truncated and cannot be expanded. No "show all", no pager, no scroll. To read what I am

approving I have to quit, open the settings file in another tool, and start over.

1. There is no third option. The choice is "trust this configuration as it stands" or "exit". What is

missing is the obvious middle: review and approve individually, or *trust the folder but drop the stored
pre-approvals and ask again as they come up*. Both are safe; neither exists.

1. The dialog does not mention everything trust unlocks. It names settings.local.json permissions only.

Nothing about .claude/settings.json hooks (which execute without any tool call), .mcp.json servers,
or CLAUDE.md. Hooks are the highest-impact item and go unmentioned.

Why this matters at scale

I audited my own machine after hitting this:

| | |
|---|---|
| Projects with a .claude config | 57 |
| Pre-approved permissions in total | 1325 |
| Broad ones (arbitrary code execution, sudo, ssh *, generic cd *, paths outside the project) | 52 |
| Projects still untrusted, i.e. that will show this dialog | 45 |

These accumulated over months, one "always allow" at a time, each reasonable in its moment. Nobody audits
them as a set — which is exactly what the dialog now asks for, at a glance, 35 at a time.

The most interesting category the audit surfaced was not the arbitrary-execution entries, but permissions
reaching outside their own project — Read() patterns pointing at unrelated directories, and a
rm -rf targeting another project's cache. Those break the per-project isolation that folder-level trust
assumes, and they are invisible in a dialog that shows eight lines.

No timestamps, and the only reconstruction path expires

settings.local.json stores a plain array. There is no record of when each permission was granted, or by
which session, so "is this configuration still what I intended?" cannot be answered.

The only reconstruction path is the session transcripts under ~/.claude/projects/<project>/*.jsonl — finding
the first tool call each permission covers. That works, but transcripts roll off after roughly 30 days: on my
machine the oldest surviving one is 30 days old and 28 of 50 project directories are already empty. I could
date 82 of 1325 permissions. The rest are unknowable.

Suggested fixes

1. Show the whole list — scrollable/pageable, or a "press v to view all" key. Never truncate individual

entries.

1. Add the missing third option:

• 3. Review permissions individually (accept/reject each), and/or
• 3. Trust folder, discard stored pre-approvals (start clean, re-prompt on demand).

1. Rank what is shown. With limited space, surface the broadest entries first — arbitrary code

execution, sudo, paths outside the project, wildcards — rather than the first eight in file order.

1. Name hooks, MCP servers and CLAUDE.md in the dialog when present. Hooks especially.
2. Record a timestamp (and ideally a session id) per entry when a permission is stored, so the set can be

audited later. Small change, lasting value.

1. Optionally, a claude permissions review command for the same job outside the launch path.

Note

The 2.1.232 change itself is right — a cloned third-party repo silently inheriting a parent's trust, and with
it its own pre-approvals, is a real hole. This report is about the dialog that now carries that decision.

---

Environment: Claude Code 2.1.232, native install, Linux (WSL2).