trailofbits/claude-code-config: an opinionated Claude Code setup you install from inside the session
Opinionated defaults, documentation, and workflows for Claude Code at Trail of Bits
At a glance
- What is it?
- Trail of Bits publishes its Claude Code defaults as a repository rather than a package. The install path is a clone, a session, and a slash command, and the contents are sandboxing, permissions, hooks, skills, MCP servers and usage notes from security audit work.
- Who is it for?
- Adopt it if you already run Claude Code on macOS and want someone else's hardened starting point for permissions, sandboxing and hooks, and you are willing to read each file before copying it into ~/.claude. Skip it if you need a supported package, a Windows path, or a drop-in installer that does not assume Homebrew and a specific terminal.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: Claude Code ships unconfigured and every team reinvents the same defaults
Claude Code runs with whatever permissions, hooks and MCP servers you happen to have configured. Nothing in the tool decides for you that a shell command should be sandboxed, that telemetry should be off, or that a subagent should not nest four levels deep. Each team ends up with a private settings.json, a private CLAUDE.md, and a private set of opinions about which of those choices are safe.
This repository is Trail of Bits answering that question in public. The README describes it as "opinionated defaults, documentation, and workflows for Claude Code at Trail of Bits", drawn from security audits, development and research. It is aimed at engineers who already use Claude Code and want a starting configuration that reflects a security firm's threat model rather than a demo. It is not a library, not a plugin you install from a registry, and not a wrapper around the CLI. The repository layout is a set of files: .claude/, commands/, hooks/, rules/, scripts/, settings.json, claude-md-template.md and mcp-template.json.
The audience matters here. The defaults assume you are comfortable with the idea that a coding agent can run arbitrary commands on your machine, and that the mitigation is sandboxing plus explicit permissions rather than prompting.
How the config is structured: settings.json, hooks, commands and rules
The centre of the repository is settings.json, a template you copy to ~/.claude/settings.json or merge into an existing file. The README notes that a $schema key enables autocomplete and validation in editors that support JSON Schema, which is the practical reason to keep the template intact rather than retyping keys.
The env block carries the privacy defaults: DISABLE_TELEMETRY for Statsig telemetry, DISABLE_ERROR_REPORTING for Sentry, and CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY. The README explicitly warns against the umbrella CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC because it also disables auto-updates. That is a concrete trade-off, and the repository takes a side: keep updates, kill the three streams individually.
The rest of the layout is behavioural rather than declarative. hooks/ holds scripts that run on Claude Code events. commands/ holds slash commands, including the /trailofbits:config command that drives installation. rules/ and claude-md-template.md shape what the model is told about your codebase. mcp-template.json is the starting point for MCP servers, and the settings template sets enableAllProjectMcpServers to false explicitly, which the README explains is already the default, set so it does not get flipped by accident. That pattern, writing down an existing default to pin it, recurs in the settings discussion and is the repository's most distinctive habit.
Installing it: clone, start a session, run /trailofbits:config
There is no package to install. The README gives a first-time setup of three commands, and the third one is the CLI itself.
git clone https://github.com/trailofbits/claude-code-config.git
cd claude-code-config
claudeInside that session you run `/trailofbits:config`. According to the README, the command walks you through installing each component, detects what you already have, and self-installs itself so future runs work from any directory. Running it again after updates is the documented upgrade path.
The prerequisites are the part people underestimate. The README recommends Ghostty as the terminal, installed on macOS with `brew install --cask ghostty`, and states it is macOS only, with Linux directed to the Ghostty install docs and Windows users pointed at WezTerm. Core tools come from a single Homebrew line covering jq, ripgrep, fd, ast-grep, shellcheck, shfmt, actionlint, zizmor, macos-trash, node@22, pnpm and uv. Python tools install through uv (ruff, ty, pip-audit), the Rust toolchain through rustup with cargo installs for prek, worktrunk, cargo-deny and cargo-careful, and Node tools with npm install -g oxlint agent-browser.
Shell setup is a small addition to ~/.zshrc. The README's first alias is the one that signals the repository's stance:
alias claude-yolo="claude --dangerously-skip-permissions"The README calls this the recommended way to run Claude Code for maximum throughput and pairs it with sandboxing. If you use local models, a second function wraps the CLI with a local server:
claude-local() {
ANTHROPIC_BASE_URL=http://localhost:1234 \
ANTHROPIC_AUTH_TOKEN=lmstudio \
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 \
claude --model qwen/qwen3-coder-next "$@"
}That function points at LM Studio on localhost:1234, which the README installs with a curl script that provides lms and llmster, or via the desktop app. Note the asymmetry: here CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC is used, because with a local model the telemetry has nowhere to go anyway, whereas the global settings template avoids it to keep auto-updates.
The env vars that pin behaviour, and why the README pins them
The settings template sets CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH to "3". The README is candid that this changes nothing today, because three is the current built-in default. The reason to write it down is that the README states the default is delivered by a remote feature flag, observed in the binary, and that the documentation does not say so. Without pinning it, the effective nesting limit can move without a release. Set it to 1 to stop subagents spawning their own.
The companion variable, CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, defaults to 20 and is deliberately left unset. The README's reasoning is that 20 is already generous and picking a lower number is a throughput guess. That is a defensible line: pin values that change your safety envelope, leave values that only change speed.
The README also gives version boundaries. Both variables exist since Claude Code v2.1.217, and the built-in depth default of 3 dates from v2.1.219, so earlier releases default differently. If you are on an older build, the pinned value is doing real work rather than documenting the status quo.
The agent teams block is the one to read twice. CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS enables multi-agent teams, which the README flags as experimental with known limitations around session resumption and task coordination. The less obvious consequence: while agent teams are on, a subagent Claude names on its own launches as a full teammate, so teams can form when you did not ask for one. That is a behavioural side effect of a flag, not a feature description, and it is the kind of thing that only shows up in a config repository maintained by people who run long sessions.
Where this setup is the wrong tool
The repository assumes macOS and Homebrew. Ghostty is described as macOS only, the core tool install is a single brew line, and Windows users are told to use WezTerm with no equivalent install path given. If your team is on Linux or Windows, you are reading this for the ideas, not for the commands.
It also assumes you accept bypassing permission prompts. The claude-yolo alias is presented as the high-throughput path, with sandboxing as the counterweight. If your environment requires per-command approval, or if you cannot run the sandbox the repository expects, the central recommendation does not apply to you and the remaining value is the settings template and the documentation.
There is a licensing gap worth naming plainly. The repository metadata does not state a licence. Copying configuration files into your own dotfiles is one thing, but vendoring hooks, scripts or rules into a product is a question you cannot answer from what the repository states. The README is silent on this.
Finally, the README does not document rollback. There is no described way to undo the components that /trailofbits:config installs, beyond re-running the command after updates. If you want a reversible setup, snapshot ~/.claude before you start, because the repository does not tell you how to get back.
The alternative: Anthropic's documented defaults versus a firm's working setup
The obvious alternative is to configure Claude Code yourself from Anthropic's documentation, which the README lists first under Read These First, alongside Simon Willison's post on using LLMs for code, Nilenso's playbook for teams, Thomas Ptacek's argument against dismissing LLMs, and OpenAI's harness engineering post.
The difference in approach is the point. Anthropic's documentation tells you what each setting does and leaves the combination to you. This repository tells you which combination Trail of Bits runs, including the parts that are opinions rather than API facts: Ghostty over other terminals, a yolo alias as the default invocation, prek and worktrunk from the Rust ecosystem, a specific set of MCP servers and skills. You can adopt the settings template without the terminal recommendation, but the repository does not present itself as a menu. It is a snapshot of one organisation's setup, and the README says so.
If you want a supported distribution with versioned releases, this is not it. The repository metadata shows no releases, and the default branch is main. Updates arrive as commits, and your upgrade step is running /trailofbits:config again.
Maintenance, upgrades and what to verify before copying
The last push to the repository was on 2026-08-24, which is recent enough that the settings reflect current Claude Code behaviour, including version boundaries the README ties to v2.1.217 and v2.1.219. There are no releases, so there is no changelog to diff between versions. Your practical upgrade mechanism is the slash command, and the README's instruction is to run /trailofbits:config again after updates.
The cost of adopting this is not installation time, it is review time. The settings template touches telemetry, error reporting and feedback surveys, plus subagent depth and concurrency, plus MCP server enablement. It also assumes a toolchain of roughly twenty binaries. Before copying anything into ~/.claude/settings.json, read the env block against your own file, because merging is the documented option and a merge can silently keep your old value.
On licensing, the repository metadata does not state a licence, so treat redistribution and vendoring as unresolved until you check. That is a fact about the repository, not a legal conclusion.
Editorial conclusion
Adopt it if you already run Claude Code on macOS and want someone else's hardened starting point for permissions, sandboxing and hooks, and you are willing to read each file before copying it into ~/.claude. Skip it if you need a supported package, a Windows path, or a drop-in installer that does not assume Homebrew and a specific terminal. Before you copy anything, verify the settings template against your own ~/.claude/settings.json, confirm the sandbox and hook scripts run on your machine, and check the licence, since the repository metadata does not state one.
Frequently asked questions
What does /trailofbits:config do in Claude Code?
It is the slash command that drives installation of the repository's components. The README states it walks you through installing each component, detects what you already have, and self-installs the command so future runs work from any directory.
Where is the Claude Code config stored for this repository?
The settings template is copied to ~/.claude/settings.json, or merged into an existing file at that path. The repository itself keeps settings.json, hooks/, commands/, rules/ and mcp-template.json at its top level.
How do I edit the Claude Code config from this repository?
You edit the files directly: settings.json for the env block and defaults, hooks/ for event scripts, commands/ for slash commands, and claude-md-template.md for the global instructions. The README's upgrade path is re-running /trailofbits:config after updates.
Where is the Claude Code config json file located?
The README points at ~/.claude/settings.json as the destination for the settings template, either copied whole or merged into an existing file. The template in the repository is settings.json at the top level.
Community notes