DEV Community: impactaky

A Deny Read Bug in Claude Code's Bubblewrap Sandbox

impactaky — Wed, 11 Mar 2026 13:15:27 +0000

While using the sandbox behavior of Claude Code on Linux, I discovered a bug where deny read rules did not work correctly in environments using Bubblewrap.

I tested and reported the issue to Anthropic, and it has now been fixed.

The fix is included in Claude Code 2.1.40 and later.

Why sandbox is required for Claude Code's `deny` rules

Sometimes users report that Claude ignores instructions like “do not read this file.”

However, these restrictions should not rely on prompts alone.

Access control must be enforced by the runtime harness configuration.

Claude Code provides a permissions.deny mechanism to block access to specific files.

For example:

deny read: ~/.ssh/**

However, for these rules to work reliably, sandboxing must be enabled.

Without sandboxing, Read is blocked by ClaudeCode, but Bash cannot be prevented.

Another common mistake is enabling dangerously-skip-permissions together with sandboxing.

When this option is enabled, commands that disable the sandbox may be automatically approved, effectively bypassing the sandbox.

The recommended setup is:

Run Claude Code in an isolated environment if possible
Enable sandbox using /sandbox
Do not enable dangerously-skip-permissions

The issue

While testing sandbox behavior, I found that certain deny rules were not enforced correctly on Linux.

Specifically, rules that included wildcard patterns such as * allowed file access through Bash under certain conditions.

This pattern appears in the official documentation, so it is something users should be aware of.

Example configuration:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Read(./build)"
    ]
  }
}

Documentation reference:

https://code.claude.com/docs/en/settings#excluding-sensitive-files

Root cause

Claude Code’s Linux sandbox uses Bubblewrap to enforce filesystem restrictions.

One mechanism used by Bubblewrap is to mount /dev/null over paths that should be unreadable.

However, the implementation did not correctly handle paths that contained wildcard patterns such as *.

As a result, the deny rule was not properly enforced in some cases, allowing file access through Bash commands.

This issue has now been fixed in Claude Code 2.1.40.

Conclusion

Sandboxing is an important safety mechanism when using AI coding agents.

This issue was discovered while evaluating the sandbox behavior of Claude Code.

It has now been fixed, so users should upgrade to the latest version.

Supporting independent security research

This investigation was conducted using my own time and Claude Code tokens.

I paused my regular work to investigate and debug this issue. Even when a report is accepted, the overall effort can still be financially negative. Submitting vulnerability reports also does not guarantee that they will be accepted or recognized as valid issues.

If you found this research useful and would like to support further work like this, please consider supporting me:

☕ https://ko-fi.com/impactaky

⭐ https://github.com/sponsors/impactaky

Thank you.

Why Agent Skills Aren't Called automatically: An Anti-Pattern in Agent Skill

impactaky — Mon, 16 Feb 2026 15:19:51 +0000

Reasons

A single context can legitimately map to multiple skills
Spec-driven planning does not reason over the available skill space

Source Code Used in the Experiment

To reproduce the behavior, I used a minimal repository containing only two skills.

lint
planner

A single context can legitimately map to multiple skills

I wanted to create a plan, so I input "Create a plan to lint.". However, this directly triggered the /lint skill.

This happened even though the planner skill description explicitly says:
“Use when the user says things like ‘create a plan’.”

In practice, explicitly calling /planner turns out to be far more reliable.

Spec-driven planning does not reason over the available skill space

When I input /planner lint, the planner sometimes discovers skills/lint/SKILL.md and incorporates it into the plan. However, this behavior is not guaranteed.

The problem becomes more obvious with inputs like:
/planner lint src directory

In this case, the planner restricts its file exploration to the src directory.
As a result, it does not discover other skills.

The planner then reasons about how to lint in general and produces a plan that ignores the lint skill’s defined procedure entirely.

I stopped using skills implicitly

When I asked Claude to fix the planner so that it considers available skills, it actually worked.

However, I was using a get-shit-done style workflow, where the system assumes that everything belongs in .planning.

At that point, I realized the core issue:

I should not be using skills to encode project-specific behavior.
Those behaviors belong in the spec, not in skills.

mise moved mypath:$PATH to $PATH:mypath

impactaky — Tue, 10 Feb 2026 14:28:03 +0000

What happened

mise save user added environment variables to $__MISE_ORIG_PATH when do mise setup.
mise check environment variables every time it is called, and if there is environment variables it isn't contained in $__MISE_ORIG_PATH, it move variable to last of $PATH.
e.g. path:uncontained:others -> path:others:uncontained.

And I'm using tmux, my setting inherit environment variable from parent tmux server.

Even I update my rc setting, $__MISE_ORIG_PATH was fixed to old environment variable.
It doesn't overwrite.

What I had to do

So I had to relaunch tmux.