npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

coding-capsule

v0.16.0

Published

Run Claude Code in a sandboxed Docker container

Downloads

122

Readme

coding-capsule

Run Claude Code in a sandboxed Docker container. The agent can read/write files in your repo but cannot access anything else on your machine (no SSH keys, AWS credentials, other repos, etc.).

Prerequisites

  • Docker installed and running
  • Node.js >= 20
  • Claude Code authenticated on your host machine (run claude once and log in)

Usage

cd /path/to/repo
npx coding-capsule

This builds a Docker image (if needed), mounts the repo and your Claude credentials into the container, and runs Claude Code in --dangerously-skip-permissions mode.

You can pass additional positional arguments through to Claude:

cd /path/to/repo
npx coding-capsule "fix the failing tests"

Global install

npm install -g coding-capsule
cd /path/to/repo
coding-capsule

CLI options

| Option | Alias | Default | Description | |--------|-------|---------|-------------| | --expose-port | -p | — | Forward a host port into the container so that localhost:<port> inside the container reaches the host. Can be specified multiple times. | | --truecolor | — | true | Set COLORTERM=truecolor inside the container. Disable with --no-truecolor. | | --version | — | — | Show version number. | | --help | — | — | Show help. |

# Forward ports 3000 and 8080 into the container
coding-capsule -p 3000 -p 8080

# Disable true-color support
coding-capsule --no-truecolor

What's sandboxed

  • Your Claude auth credentials (~/.claude and ~/.claude.json) are snapshotted (copied) into the container — the container cannot modify the originals. Session history and project settings mount directly for persistence.
  • No access to ~/.ssh, ~/.aws, ~/.config, or any other host files
  • Network is open (the agent needs it for npm, docs, etc.)
  • The Docker image is built automatically from an embedded Dockerfile — no manual setup required
  • The container runs as the same UID/GID as your host user, so file ownership in the repo is preserved

[!WARNING] Your Claude Code credentials are readable inside the container. A prompt injection attack (e.g., malicious instructions hidden in a repo file) could exfiltrate them over the network. The credentials are only useful for Claude API calls — they cannot access your machine, GitHub, or other services. The exact blast radius depends on the authentication method (OAuth token vs. raw API key). To mitigate this, you could add an egress proxy that restricts outbound traffic to known-good domains.

Security analysis

For a detailed breakdown of the security posture, see blastradius.md — risk profile, attack surface, and mitigations.

Rationale

The problem

Running a coding agent in --dangerously-skip-permissions mode (auto-approve all actions) is convenient but risky. A bad actor can embed prompt injection instructions in repo files (README, code comments, issue descriptions) that trick the agent into running arbitrary commands on your machine — deleting files, exfiltrating secrets, installing backdoors, etc.

We don't care about the agent messing with the repo itself — it's source-controlled and trivially reversible with git checkout . && git clean -fd. The threat is the agent reaching outside the repo to the rest of the local machine.

Approaches considered

Claude Code hooks (command blocklist). Configure hooks that intercept every Bash call and block patterns like rm -rf ~, curl ... | sh, access to ~/.ssh, etc. This is easy to set up but fundamentally a blocklist — a sufficiently creative injection can bypass it via encoding, aliasing, or indirect execution. It's a speed bump, not a wall.

Bubblewrap (bwrap). A lightweight Linux sandboxing tool that uses kernel namespaces (same as Docker) but without a daemon, images, or root access. You selectively mount only the directories the process needs. The advantage over Docker is that auth "just works" since it runs natively on the host. The downside is more fiddly to set up and less familiar to most people.

Docker with --network=none. The strongest isolation — no filesystem access outside the mounted repo, no network. But coding agents legitimately need network access for installing packages, reading library docs, searching npm, etc. So this is too restrictive.

Docker with egress proxy. Run a filtering proxy (e.g., squid) that only allows traffic to known-good domains (npmjs.org, github.com, stackoverflow.com, etc.). This prevents exfiltration while allowing legitimate network use. Effective but high maintenance — you need to keep the allowlist up to date.

Docker with open network and minimal host mounts. Only the repo and Claude credentials are bind-mounted from the host. Network is unrestricted. The agent can't touch anything else on the host machine, but it can make outbound network requests. The only sensitive data it could exfiltrate is the repo's source code and the mounted Claude session credentials.

Dedicated VM. Run the agent on a throwaway cloud instance or local VM with nothing of value on it. Strongest isolation but heaviest setup.

What we chose

Docker with open network and minimal host mounts. It's the pragmatic sweet spot:

  • Fully protects the host machine (no access to SSH keys, AWS creds, other repos, etc.)
  • Agent can still use the network for legitimate purposes (npm, docs, etc.)
  • Simple to set up — npx coding-capsule from your repo directory and you're running
  • Repo damage is irrelevant (source-controlled)

The trade-off is that the Claude Code credentials are readable inside the container and could theoretically be exfiltrated over the open network. We accept this because (a) the credentials are only useful for Claude API calls — they cannot access your machine, GitHub, or other services, and (b) adding an egress proxy to close this gap is possible but adds significant complexity.

Undoing changes

The agent can only modify files in the repo you passed in. Since it's source-controlled:

cd /path/to/repo
git checkout .
git clean -fd