A Cline user configured project-level permission rules for the Claude Code provider, same as always. The rules silently did nothing. No prompt, no error, no indication anything was being blocked — tool calls just failed.
What the source says
cline/cline#14699, filed September 30, 2026 against Cline v4.1.21 (VS Code extension), using the Claude Code provider with Claude Sonnet 5 and Claude Code CLI 2.1.263. The reporter (csimonb) gave five numbered repro steps: create a workspace folder plus a folder outside it, ask the agent to read/write the outside folder and run a shell command (both refused, no prompt), add permission rules to the project's .claude/settings.json (no effect), then move the identical rules to the user-level ~/.claude/settings.json — where they work.
The reporter traced the cause to Claude Code's own CLI output, which Cline never surfaces: Ignoring 2 permissions.allow entries from .claude/settings.json: this workspace has not been trusted. Claude Code has a workspace-trust gate that disables project-level permission rules until a workspace is explicitly trusted. The CLI logs that fact. Cline's UI doesn't show the log line, so the user just sees permission-gated calls — terminal commands, MCP tool calls, out-of-workspace reads/writes — get refused with nothing actionable to go on.
A Cline contributor (Dante-dan) confirmed the trust-gate explanation, while flagging that it doesn't by itself rule out a separate permission-merge bug. The issue was still open with no fix merged as of this incident's publication.
What it doesn't establish
This is one reporter's issue with one contributor's partial confirmation — no independent third-party reproduction is on record, and the "doesn't rule out a separate bug" caveat means the full extent of the merge behavior isn't settled. No data loss or security impact was reported; the cost here is entirely a debugging dead end; a configured permission rule has no effect and nothing in the UI says why.
Why it's still worth logging
Claude Code's workspace-trust gate is working as designed — it's not an agent misbehaving, it's a security boundary. The failure is that the boundary is invisible through this provider integration: a developer who sets scoped permissions at the project level, the recommended place to put them, gets refused calls with no signal that trust, not the rule itself, is the blocker. The CLI already prints the answer. It just never reaches the person who needs it.
Full record, severity scoring, and frontmatter: https://www.stupidllm.com/incident/STUPID-2026-0138/
Top comments (0)