Workspace Trust Is the New Git Hooks Problem

Repositories can carry instructions now

Developers already know to be careful with Git hooks, workflow files, package scripts, Dockerfiles, and editor tasks. Agentic coding tools add another category: workspace configuration that changes what the agent is allowed to do.

That makes workspace trust a control surface, not a UX nicety.

The Claude Code trust-bypass pattern

Public advisories for CVE-2026-33068 describe a configuration-loading issue where repo-controlled Claude Code settings could influence permission mode before the workspace trust dialog appeared. The lesson is broader than one tool or one version: untrusted repository state must not decide whether the repository is trusted.

That sounds obvious in hindsight. Most security bugs do.

What to review in shared repos

Treat agent configuration like automation code:

• Review .claude/, MCP configuration, editor tasks, workflow files, and package scripts before opening an unfamiliar workspace with elevated agent permissions.
• Keep default modes conservative for unknown repositories.
• Separate “read and inspect” from “write and execute.”
• Pin tool versions when security advisories mention permission or trust-model fixes.
• Consider a quarantine workspace for unknown client repos and public proof-of-concept code.

The durable rule

Trust prompts must be based on trusted inputs. If repository-controlled files can decide whether a prompt appears, the prompt is already downstream of the attacker.

That same rule applies to IDEs, coding agents, MCP clients, CI workflows, and local automation wrappers.

Source note

This note is based on the GitLab Advisory Database entry for CVE-2026-33068, the related RAXE Labs advisory, and Anthropic's public notes on Claude Code permission modes.