[BUG] Trust dialog no longer offers "No, continue without these permissions" (regression since 2.1.234)
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?
The workspace trust dialog used to offer three options. It now offers two, and the one that was removed is the only one that let a user start work without accepting permission rules they had not read. I can find no changelog entry for the removal.
On 2.1.234, for a folder with pre-approved permissions, the dialog offered:
> 1. Yes, I trust this folder
2. No, continue without these permissions
On 2.1.282, the current release, it offers:
❯ No, exit
Yes, I trust this folder
I checked five configurations across three versions: on 2.1.278, 35 rules at 80×24, 35 rules at 200×60 and 35 rules in a git repo at 120×40; on 2.1.280 and again on 2.1.282, 3 rules at 120×40. All five show the same two options. @flo-az's paste in #94277, captured independently on 2.1.270, shows the same two. So the option was removed somewhere between 2.1.234 and 2.1.270.
The minimal case matters here, so I want to be explicit about it: with 3 rules the entire list is displayed, nothing is hidden, and the third option is still absent. The removal is unconditional. It is not a side effect of the list being truncated.
One thing did improve in the same period, and it is worth stating: the accepting option is no longer the default. No, exit now carries the cursor, where in August Yes, I trust this folder was listed first. #90582 asks for that ordering to be reverted, on the grounds that accepting now costs an extra keypress. I understand the annoyance, but I would ask that the safe default survive whatever is decided there — and that it not be treated as a substitute for the third option, because it is not one. A default protects a user who presses Enter
What Should Happen?
Restore No, continue without these permissions as a third option, so that a folder can be opened without its permissions.allow rules being applied.
Without it, a user facing a folder whose rules they have not reviewed has two choices: accept all of them, or not work in the folder at all. Claude Code already implements the principle this option embodies. From the 2.1.235 changelog, about permission dialogs:
display text and "don't ask again" options now always match what a grant would cover, and "don't ask again" is withheld when contents cannot be fully displayed
That is exactly right, and the trust dialog now goes the other way: it offers the blanket grant, and has removed the path that declines it.
Error Messages/Logs
Steps to Reproduce
- Create a directory that has never been trusted, with a small permissions file:
``sh``
mkdir -p /tmp/trustrepro/.claude && cd /tmp/trustrepro
cat > .claude/settings.local.json <<'JSON'
{"permissions":{"allow":["Bash(dpkg -l)","Bash(apt list *)","Bash(jq *)"]}}
JSON
Confirm the folder is not already trusted:
``sh``
python3 -c 'import json,os;print("/tmp/trustrepro" in json.load(open(os.path.expanduser("~/.claude.json"))).get("projects",{}))'
This should print False. The dialog does not fire for a folder that already has a trust entry, so if it prints True, or if the path has been used before, pick a fresh one.
- Run
claudein that directory.
- The dialog lists the 3 pre-approved permissions in full, then offers
No, exitandYes, I trust this folder. There is no third option.
Expected: a third option that proceeds into the session with the folder's permissions.allow rules not applied.
Relationship to other issues
This is not a duplicate of #87012, which I also filed. That issue is about what the dialog shows — it names 8 of 35 rules and collapses the rest. This one is about what the dialog offers, and reproduces with a list short enough to be shown in full. The two have different fixes and either can be resolved without the other.
#90582 reports the reordering of the same dialog's options, from the opposite direction, and also notes the absence of a changelog entry. I have not found an entry for either change anywhere in 2.1.234 through 2.1.282.
For context on why I am filing rather than commenting: #73917, in this same area, was closed as completed on 25 Aug after a maintainer attempted a repro on a recent release and asked for version and platform if the behaviour persisted. That is the shape I have tried to give this report: current version, exact configurations tested, and a repro that takes four lines.
Environment
Claude Code 2.1.282 (also reproduced on 2.1.278 and 2.1.280), native install, WSL2 (Ubuntu 24.04, kernel 5.15.133.1-microsoft-standard-WSL2), Windows Terminal.
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.234
Claude Code Version
2.1.282 (Claude Code)
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
WSL (Windows Subsystem for Linux)
Additional Information
_No response_