Complete reference for the tools Claude Code can use, including permission requirements and per-tool behavior.

Claude Code also keeps a fifth file, ~/.claude.json, that it writes for itself; you don’t need to edit it. It holds your sign-in session, MCP server configurations, per-project state such as trust decisions, and the global config keys that /config writes for you.

Claude Code stores its configuration and auth credentials in ~/.claude by default. The CLAUDE_CONFIG_DIR environment variable overrides this location. By creating a separate config directory per account - each with its own OAuth credentials - and symlinking shared resources back to a canonical source, you get:

• Separate billing/authentication per account
• Shared sessions - resume any session from either account
• Shared settings, plugins, commands, plans, and skills - configure once, use everywhere

​ One-Time Setup This setup is done once on your machine, outside of Maestro. ​

1. Authenticate Each Account Start Claude Code normally and complete OAuth for your first account:

claude

Complete OAuth for account A (e.g., personal)

Copy the authenticated config to a named directory:

cp -a ~/.claude ~/.claude-personal

Then authenticate your second account:

mv ~/.claude/.claude.json ~/.claude/.claude.json.bak claude

Complete OAuth for account B (e.g., work)

cp -a ~/.claude ~/.claude-work rm ~/.claude/.claude.json.bak

The main ~/.claude/ directory doesn’t need its own .claude.json. It serves as the canonical source for shared resources.

​ 2. Symlink Shared Resources For each account directory, replace local copies with symlinks back to ~/.claude so settings, plugins, and sessions stay in sync:

Repeat for each account directory (e.g., ~/.claude-personal, ~/.claude-work)

CONFIG_DIR=~/.claude-personal

Back up directories that will be symlinked

mv $CONFIG_DIR/projects $CONFIG_DIR/projects-pre mv $CONFIG_DIR/todos $CONFIG_DIR/todos-pre mv $CONFIG_DIR/session-env $CONFIG_DIR/session-env-pre

Remove files/dirs that will become symlinks

rm -rf $CONFIG_DIR/commands $CONFIG_DIR/ide $CONFIG_DIR/plans $CONFIG_DIR/plugins $CONFIG_DIR/skills rm -f $CONFIG_DIR/settings.json $CONFIG_DIR/CLAUDE.md

Create symlinks

ln -s ~/.claude/commands $CONFIG_DIR/commands ln -s ~/.claude/ide $CONFIG_DIR/ide ln -s ~/.claude/plans $CONFIG_DIR/plans ln -s ~/.claude/plugins $CONFIG_DIR/plugins ln -s ~/.claude/skills $CONFIG_DIR/skills ln -s ~/.claude/settings.json $CONFIG_DIR/settings.json ln -s ~/.claude/CLAUDE.md $CONFIG_DIR/CLAUDE.md ln -s ~/.claude/todos $CONFIG_DIR/todos ln -s ~/.claude/session-env $CONFIG_DIR/session-env ln -s ../.claude/projects $CONFIG_DIR/projects

Set CLAUDE_CONFIG_DIR to your account’s config path (e.g., /Users/you/.claude-personal)

Here's how I use the dangerous flag safely:

1. Environment Isolation For greenfield projects or major changes, I work in isolated environments. You can set up a simple Docker container specifically for Claude development:

This gives Claude a safe sandbox to work in without risking your main system. Because I love using Makefiles, here is the one I use for essential tasks:

2. Task Scoping The quality of your results depends entirely on how well you scope the initial task. Compare these approaches:

Bad: "Build me a financial analysis system"

Good: "Build me a financial data aggregator that does A, B, and C. Look in these specific files, follow this expected flow, create tests that validate each iteration you make, ensure changes are small and incremental."

3. Sensitive Data Precautions Never use the dangerous flag in directories containing:

API keys or secrets Production configuration files Important datasets without backups System configuration files 4. Review Strategy For longer autonomous runs, I often ask Claude to create documentation or a changelog as it works. This makes the post-work review much more manageable.

Anthropic say that Cowork can only access files you grant it access to—it looks to me like they’re mounting those files into a containerized environment, which should mean we can trust Cowork not to be able to access anything outside of that sandbox.

Update: It’s more than just a filesystem sandbox—I had Claude Code reverse engineer the Claude app and it found out that Claude uses VZVirtualMachine—the Apple Virtualization Framework—and downloads and boots a custom Linux root filesystem.

I recently learned that the summarization applied by the WebFetch function in Claude Code and now in Cowork is partly intended as a prompt injection protection layer via this tweet from Claude Code creator Boris Cherny:

Summarization is one thing we do to reduce prompt injection risk. Are you running into specific issues with it?

The Tool Search Tool lets Claude dynamically discover tools instead of loading all definitions upfront. You provide all your tool definitions to the API, but mark tools with defer_loading: true to make them discoverable on-demand. Deferred tools aren't loaded into Claude's context initially. Claude only sees the Tool Search Tool itself plus any tools with defer_loading: false (your most critical, frequently-used tools).

With Programmatic Tool Calling:

Instead of each tool result returning to Claude, Claude writes a Python script that orchestrates the entire workflow. The script runs in the Code Execution tool (a sandboxed environment), pausing when it needs results from your tools. When you return tool results via the API, they're processed by the script rather than consumed by the model. The script continues executing, and Claude only sees the final output.

I run six Claude Code agents in parallel from my phone. No laptop, no desktop—just Termius on iOS and a cloud VM.

The loop is: kick off a task, pocket the phone, get notified when Claude needs input. Async development from anywhere.

Fascinating prompt engineering and injection (harmless).