STUPID-2026-0138

Cline's Claude Code provider silently refuses permission-gated tool calls with no approval prompt

3.0low
September 30, 2026VerifiedReproducible

  1. Instruction given

    Using Cline's Claude Code provider, read and write a file outside the workspace folder and run a terminal command (`python3 -c "print(42)"`).

  2. Expected behavior

    A tool call that Claude Code's permission model requires approval for should surface an approval prompt to the user, or at minimum report why the call was refused.

  3. Actual behavior

    The out-of-workspace file access and the terminal command were both refused with no approval prompt and no visible explanation in Cline's UI — the model saw a "requires approval" error, but the user saw nothing actionable. Project-level permission rules in `.claude/settings.json` had no effect, while identical rules in the user-level `~/.claude/settings.json` worked. The reporter later found the cause in Claude Code's own CLI output: it prints "Ignoring 2 permissions.allow entries from .claude/settings.json: this workspace has not been trusted" when a workspace is untrusted, but Cline never surfaces that message, so the refusal looks unexplained.

  4. Damage

    No data loss or security impact reported. The cost is that a permission rule a developer explicitly configured at the project level silently does nothing in an untrusted workspace, with no indication to the user that this is happening or why — tool calls simply get refused. A Cline contributor (Dante-dan) confirmed the workspace-trust explanation but noted it does not by itself rule out a separate permission-merge bug. As of this incident's publication the issue is open with no fix merged.

A Cline user (csimonb), running VS Code extension v4.1.21 with the Claude Code provider (Claude Sonnet 5, Claude Code CLI 2.1.263), reported that any tool call needing Claude Code's permission — terminal commands, MCP tool calls, and reads or writes outside the workspace — is refused with no approval prompt. The issue gives five numbered reproduction steps: create a workspace folder and an outside folder, ask the agent to read/write the outside folder and run a shell command (both refused with 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 workspace-trust gate: the CLI logs "Ignoring 2 permissions.allow entries from .claude/settings.json: this workspace has not been trusted" when a folder hasn't been trusted, but Cline does not surface that message anywhere in its UI, so the user just sees tool calls fail for no stated reason. A Cline contributor (Dante-dan) confirmed the trust-gate finding while cautioning it doesn't rule out a separate permission-merge issue, and proposed exposing scoped launch-time permissions and documenting the trust requirement. The issue remains open with no fix merged as of this incident's publication.

Classification

Agent
Cline
Failure mode
Logic Error
Root cause
Other
Domain
Other
Source
Github Issue

Related incidents

10.0
Clinejection: an AI issue-triage workflow enabled arbitrary code execution on the CI runner
8.4
Amazon AI coding agent mistake blamed on human employees
7.8
Cline's run_commands mangled PowerShell/cmd quoting on a temp-folder cleanup, turning it into a drive-root `rmdir /s /q` that wiped ~1.5TB of a user's photos, videos, and documents (GitHub #14864)
5.8
Cline's hub daemon silently reverted workspace files to stale state, repeatedly erasing a gitignored .env.local and collapsing a node_modules folder from 588 entries to 2 (GitHub #14819)
Discuss on Hacker News

Get told when an agent breaks something

We document AI agent failures daily, severity-scored against a published scale. When one lands at 7.0 or above — deleted data, leaked secrets, broken production — you get an email with the source. When nothing does, you get nothing.

This database is callable over MCP — query it from inside your agent.