Development Configurations: Tuning Claude's Work Environment

📚 Series Navigation: The previous article 45 Agent SDK taught you how to extract Claude Code's capabilities and embed them into your own programs. This article returns to the terminal where you type daily—tuning five aspects of Claude's "work environment": where it runs, what it can access, whether it uses a proxy, what it looks like, and which model it runs. We'll explain the most common development configurations.

Let's begin with a scenario that many developers encounter.

Many use Claude Code for the first six months with the default out-of-the-box configurations. Then, they take on a private repository for a client. Unfamiliar with the code, they worry: if it contains scripts that trick Claude into running arbitrary commands, they execute directly on their daily-use Mac—accessing SSH keys, npm credentials, and local workspaces. The typical manual defense? Staring at every command with hand on Ctrl+C. After an afternoon of stressful monitoring, they are exhausted and have accomplished nothing.

In fact, the solution is already provided—simply run Claude inside an isolated environment, using a sandbox, container, or virtual machine. Whatever it executes inside cannot harm your host. Staring at commands all afternoon is an unnecessary struggle due to not reading the docs.

We share this to help you avoid this pitfall. Development configurations are often overlooked but can save time, money, and stress. Today, we select five common configurations to explain: what they solve, when to enable them, and how.

After reading this article, you will get:

• A brief breakdown of what each of the five configuration areas (Sandbox, Devcontainer, Network, Terminal, Model) solves and when to adjust them
• How to enable the Sandbox via /sandbox, reducing permission prompts while keeping execution isolated
• What a devcontainer is, how it differs from a sandbox, and why development teams benefit from it
• How to connect Claude Code behind corporate proxies or firewalls (highly relevant for users behind network blocks)
• The three most useful terminal tweaks (newline binding, notifications, themes) and how to configure models to save credits
• A hands-on practice with expected output: enable a sandbox and lock model selections to verify the settings

---

01 Build a Framework: Five Aspects of Claude's Work Environment

Before making changes, categorize them in your mind. "Development configurations" are not random switches; they manage five facets of the same thing—Claude's work environment.

Analogy: Setting up a workstation for a new employee. When an employee (Claude) arrives, you must arrange their workspace: which room they work in (on your host machine or inside an isolated room), where the doors/windows lead (network access and corporate firewalls), whether the desk and lighting are comfortable (newline keystrokes, notifications, styling), and whether they are assigned a senior developer or an intern (which model to run). Organizing these ensures they work efficiently without causing incidents. Development configurations are this "workstation setup."

In Claude Code, these five areas are:

• Isolation (where it works)—Sandbox / Devcontainer, determining how much of your host machine Claude can access when executing commands.
• Network (where doors/windows lead)—Proxy and certificate configurations, determining connectivity behind corporate firewalls.
• Terminal (whether the desk is comfortable)—Newline keys, notifications, color themes, and Vim mode, adjusting interactive ergonomics.
• Model (who is assigned)—Opus, Sonnet, or Haiku, balancing intelligence and cost.

Configuration Area	What It Solves	When to Adjust It
Sandbox	Reduces prompts while keeping execution isolated	Annoyed by permission prompts, or handling untrusted repositories
Devcontainer	Provides an identical, isolated environment for the team	Team collaboration, unattended runs, or onboarding standardized environments
Network Configuration	Enables connection behind corporate proxies or firewalls	Cannot reach api.anthropic.com, or corporate TLS inspection blocks traffic
Terminal Configuration	Tuning newlines, notifications, and styling	Shift+Enter doesn't insert a newline, or no terminal chime when tasks finish
Model Configuration	Select models based on tasks to control costs	Burning credits too quickly, or delegating tasks to specific models

You don't need to memorize this table, but recognize which category your issue falls into—if it fails to connect, it's a network issue, so don't check sandbox settings; if you are annoyed by permission prompts, adjust the sandbox rather than the model. Once clarified, read the relevant sections as needed.

💡 Summary in one sentence: Development configurations manage five aspects of Claude's "work environment"—where it isolates work (Sandbox/Devcontainer), where its traffic routes (Network), how comfortable it feels (Terminal), and who is assigned the task (Model); identify your issue first, then adjust the corresponding setting.

---

02 Sandbox: Reducing Prompts While Restricting Access

Let's start with the most practical yet often overlooked feature—the sandboxed Bash tool. This is a built-in feature of Claude Code, enabled with a single command.

The Dilemma It Solves

You have likely faced a dilemma: wanting Claude to execute smoothly, but fearing it might cause damage. Permission modes (discussed in Chapter 20) represent two extremes—either prompting you for every command (annoying), or running autonomously without prompts (risky). The sandbox provides a middle ground.

Analogy: Racing on a dedicated test track. You don't take an untested car onto city streets—any crash hurts pedestrians or yourself. But on a closed track: solid walls surround the track, preventing the vehicle from flying off, meaning you don't need to hover over the brakes. A sandbox is this test track for Claude—restricting what files each Bash command can write and what domains it can access at the OS level. Claude runs freely inside the boundary without prompts; it only pauses for your approval if it attempts to cross the line (e.g., accessing an unapproved network domain).

The official documentation defines this accurately:

The Bash sandbox allows Claude to run most shell commands without pausing to request permission. Instead of approving every command, you define what files and network domains commands can touch, and the operating system enforces that boundary for each Bash command and its subprocesses.

Notice "enforces that boundary at the operating system level"—this is not Claude "promising not to leave the box," but the host OS physically blocking it. This differs from writing "do not run arbitrary commands" in CLAUDE.md: one is a soft prompt, the other is a hard wall.

How to Enable: The /sandbox Command

The sandbox is built into Claude Code, supported on macOS, Linux, and WSL2, but not native Windows (Windows users should run inside WSL2). Enabling it takes one command inside the session:

/sandbox

This opens a control panel with three tabs:

• Mode: Select "Auto-allow" or "Normal permissions." Auto-allow = sandboxed commands execute without prompts (the main benefit of the sandbox); Normal permissions = prompts appear even if the command is sandboxed.
• Overrides: Controls whether commands that fail inside the sandbox can fall back to unsandboxed execution (corresponds to the allowUnsandboxedCommands setting).
• Config: Inspects the active sandbox boundaries.

Platform requirements vary:

• macOS: No installations required. The sandbox leverages the built-in Seatbelt framework, working out of the box.
• Linux / WSL2: Relies on two packages—bubblewrap (for file isolation) and socat (for network relay). If missing, the /sandbox panel displays a "Dependencies" tab listing missing tools; install them (on Ubuntu/Debian: sudo apt-get install bubblewrap socat), restart Claude Code, and enable it.

The default boundary is restrictive—sandboxed commands can only write to the current working directory, and the agent prompts you when a command attempts to connect to a new network domain for the first time. The selected mode is saved in the project's .claude/settings.local.json (local-only, not committed to Git). To default to sandboxing across all projects, set sandbox.enabled to true in user-level ~/.claude/settings.json (configuration levels are detailed in Chapter 31).

A minor pitfall: if the sandbox fails to initialize due to missing dependencies or platform limitations, Claude Code prints a warning and runs unsandboxed by default without blocking execution. This design avoids interrupting workflows but means you might assume isolation is active when running on the host. Verify isolation status (using the steps in Section 07) in sensitive settings. If you require a hard block when isolation fails, set sandbox.failIfUnavailable to true.

A Key Limitation: Sandbox Only Targets Bash

This is critical: the built-in sandbox only restricts Bash commands. Other Claude actions—reading or editing files (Read/Edit tools), scraping URLs (WebFetch), and running MCP servers or hooks—execute directly on your host machine without sandbox constraints.

The official documentation states this clearly:

Built-in file tools, MCP servers, and hooks still run directly on your host machine.

Thus, the built-in sandbox is suited for "local development on your own machine, reducing permission prompts." If you want to isolate the entire Claude Code process (including file tools, MCP, and hooks), utilize devcontainers (next section) or the experimental sandbox runtime—which encapsulates the entire process. Typically, keep the built-in sandbox active for daily convenience, upgrading to containers when handling untrusted code.

💡 Summary in one sentence: The sandbox uses /sandbox to isolate Bash commands at the OS level, allowing them to run without prompts within defined file/network boundaries; however, remember it only restricts Bash, leaving file tools, MCP, and hooks running directly on the host.

---

03 Devcontainers: Standardized Isolated Workspaces for the Team

The sandbox isolates commands on your host. A devcontainer (Development Container) takes it a step further—running the entire Claude environment inside a separate workspace container.

The Dilemmas It Solves

Two common pain points necessitate devcontainers:

First, inconsistent environments across the team. If your machine runs Node 18 and a colleague's runs Node 20, Claude may output conflicting results. Second, unattended executions. Running a long task while you step away is convenient, but letting Claude run unchecked on your host machine introduces security risks.

Analogy: A library study room. Working in an open desk area (your host) exposes your personal belongings to bypassers, and you can't step away. Reserving a private study room is different: it provides standard library equipment (identical for everyone), and closing the door isolates your work without exposing personal items. A devcontainer is that study room—a standardized, isolated environment defined by configuration files, preventing Claude from touching host SSH keys or private credentials.

The official definition:

A development container (or dev container) lets you define an identical, isolated environment that every engineer on your team can run. With Claude Code installed in the container, commands run inside the container rather than on your host, while edits to project files appear in your local repository as you work.

Notice the feature: commands run inside the container, but file modifications sync directly to your local workspace. This delivers "isolated execution, local updates" simultaneously.

How to Configure: Adding a Feature and Rebuilding

Devcontainers require Docker and an editor supporting the Dev Containers specification (VS Code, Codespaces, JetBrains, Cursor, etc.). Installing Claude Code inside the container involves adding a feature definition to .devcontainer/devcontainer.json:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

The features block references the official Claude Code Dev Container Feature, which installs Claude Code inside the container. Adjust the image field to match your project's base image. Run Dev Containers: Rebuild Container via the Command Palette (Cmd+Shift+P / Ctrl+Shift+P), and log in by running claude inside the container terminal.

A common pitfall: the container's home directory is typically discarded during rebuilds, requiring you to re-authenticate claude each time. To persist credentials, map a named volume to ~/.claude. This is an advanced setup—know that it exists, and refer to devcontainer documentation to mount volumes if needed.

A security reminder highlighted in the official docs:

Only use development containers when developing with trusted repositories, and monitor Claude's activity. Avoid mounting host keys (such as ~/.ssh or cloud credential files) into the container.

In plain English: a container is a layer of defense, not absolute immunity. Especially if you configure it to skip permission prompts during unattended runs, malicious scripts can still compromise resources accessible inside the container. Avoid mounting host SSH keys for convenience—use repository-scoped, short-lived tokens instead.

Devcontainer vs. Sandbox

Both offer "isolation" but target different scopes. Here is a comparison of Sandbox, Devcontainer, and other official isolation mechanisms:

Isolation Mode	Restricted Scope	Requires Docker?	Best Suited For
Built-in Sandbox	Restricts only Bash commands	No	Local development on own machine, reducing prompts
Devcontainer	The entire development environment	Yes	Standardizing team environments, unattended execution
Custom Container / VM	The entire environment / OS	Yes for containers, No for VMs	Executing untrusted code requiring kernel-level isolation
Claude Code on the web (Chapter 11)	The entire OS, hosted by Anthropic	No	Bypassing local setups, or running without local resources

This diagram lines up the five isolation levels: leftmost is "no isolation, Claude operates directly on your host," and moving right expands the restricted scope—from the built-in sandbox (Bash only), to devcontainers (the environment), to virtual machines, and finally to cloud environments. The less you trust the code, the further right you should choose.

Guidelines for selecting isolation modes:

• Local development, minimizing prompts: use the built-in sandbox via /sandbox.
• Standardized team environment / Unattended runs: use devcontainers, committed to the repository for shared use.
• Untrusted codebase: use dedicated VMs or the web sandbox, requiring kernel-level isolation.

In practice: keep the built-in sandbox active for personal projects; use devcontainers or run inside Claude Code on the web for unfamiliar external repositories—preventing the need for manual prompt monitoring.

💡 Summary in one sentence: A devcontainer provides a standardized isolated workspace for the team—running commands inside a container (shielding host keys) while syncing code edits locally; it differs from the built-in sandbox by isolating the entire workspace instead of just Bash commands.

---

04 Network Configuration: Connecting Behind Proxies and Firewalls

This section is for developers working behind corporate proxies or experiencing connectivity blocks to Anthropic. Skip if your connection routes normally.

The Connectivity Issues It Solves

Claude Code must connect to Anthropic servers (or your configured provider). Corporate networks often enforce restrictions: routing all outbound traffic through proxies, executing TLS inspection (using self-signed certificates), or filtering traffic through firewall allowlists. Misconfiguring any of these blocks Claude Code, causing failures during login or API requests.

Analogy: Working in a high-security office building. You (Claude Code) want to place an outbound call, but all outbound lines must route through a central switchboard (proxy). Additionally, security checks all parcels (TLS inspection), and you must recognize the security stamp (self-signed certificate) to accept them. Network configuration tells Claude Code the proxy address and the certificate details.

Note: These settings can be configured via environment variables or written in settings.json. For clarity, we will demonstrate using environment variables.

Proxies: Three Standard Environment Variables

Claude Code respects standard proxy variables; export them in your terminal:

# HTTPS proxy (Recommended)
export HTTPS_PROXY=https://proxy.example.com:8080

# HTTP proxy (Fallback)
export HTTP_PROXY=http://proxy.example.com:8080

# Bypass proxy for these addresses
export NO_PROXY="localhost,127.0.0.1,.internal.company.com"

Two warnings: first, Claude Code does not support SOCKS proxies—it only accepts HTTP/HTTPS; you must bridge SOCKS traffic through a gateway. Second, pass username and password credentials directly in the URL if required (http://user:pass@proxy...), but avoid hardcoding credentials in files; utilize environment variables instead.

Self-Signed Certificates: Pointing to Your CA

If your organization uses TLS inspection (e.g., Zscaler, CrowdStrike), Claude Code defaults to trusting both its bundled Mozilla CA store and the operating system trust store—it typically works without extra configurations as long as the corporate root certificate is installed in the OS. If it fails, point explicitly to your CA file:

export NODE_EXTRA_CA_CERTS=/path/to/your-company-ca.pem

Firewall Allowlists: Domains to Open

If you configure firewalls or need to coordinate with IT, these are the core domains Claude Code accesses (when connecting directly to Anthropic):

Domain	Purpose
api.anthropic.com	Claude API requests (Core)
claude.ai	claude.ai login and authentication
platform.claude.com	Anthropic Console authentication
downloads.claude.ai	Plugin downloads, native installers, and auto-updates
storage.googleapis.com	Legacy installers and updates (pre-v2.1.116)
bridge.claudeusercontent.com	Chrome extension WebSocket bridge
raw.githubusercontent.com	/release-notes source and extension counts

Connectivity Blocks: If directly connecting to Anthropic domains is blocked on your network, configure a proxy connection or use the third-party proxy/alternative model routes discussed in Chapter 04 and Chapter 05. The proxy configurations detailed here can point to your local proxy gateway. If using Amazon Bedrock or Google Vertex AI, traffic routes through their endpoints, rendering Anthropic domain allowlists unnecessary.

A typical case with tools like Zscaler is failure to log in initially, assumed to be an account error. Once IT pushes the corporate root cert to the system trust store, connectivity works without setting any environment variables. When encountering TLS errors, verify the root certificate in the OS trust store first; that is usually the fix.

💡 Summary in one sentence: Behind corporate firewalls, define HTTPS_PROXY (SOCKS is not supported) and NODE_EXTRA_CA_CERTS for self-signed certificates (though installing them in the OS trust store is preferred); ensure api.anthropic.com is allowlisted, routing through proxy tunnels or endpoints when direct connection is blocked.

---

05 Terminal Configurations: Newlines, Notifications, and Themes

While the previous sections covered security and connectivity, this section addresses configurations that affect daily ergonomics. Claude Code works inside terminals out of the box; these settings fix minor interactive inconveniences.

1. Shift+Enter Triggers Submission Instead of Newline

This is an immediate point of confusion. Pressing Shift+Enter to insert a newline accidentally submits the prompt.

A universal fallback: pressing Ctrl+J inserts a newline in any terminal, or type \ followed by Enter. These require no configuration.

Whether Shift+Enter behaves correctly depends on the terminal app:

Terminal App	Shift+Enter Behavior
iTerm2, Ghostty, Kitty, Apple Terminal, Windows Terminal, WezTerm, Warp	Works natively without configuration
VS Code, Cursor, Devin Desktop, Alacritty, Zed	Run /terminal-setup once
gnome-terminal, JetBrains IDE (PyCharm, etc.)	Unsupported; use Ctrl+J or \ then Enter

For editors like VS Code or Cursor, run this command in the chat:

/terminal-setup

This updates the terminal mapping settings without modifying existing keybindings; restart the editor to apply it. Run this directly on the host shell, avoiding tmux or screen sessions, as it must interface with the host terminal configuration.

2. No Notification When Long-Running Tasks Complete

When starting a long-running task, you might switch windows. When it completes or pauses for permissions, you miss it. The fix is enabling a notification chime or desktop alert.

By default, only Ghostty, Kitty, and iTerm2 support native desktop notifications. For other terminals, configure preferredNotifChannel to "terminal_bell" in ~/.claude/settings.json to trigger a terminal chime:

{
  "preferredNotifChannel": "terminal_bell"
}

With notifications enabled, you can start a task, walk away, and hear when it requests attention, improving productivity. For advanced setups (e.g., custom sound scripts), configure notification hooks, which are detailed in Chapter 33.

3. Styling Theme Mismatches the Terminal

Claude Code can align its colors with your terminal's light or dark theme. Run:

/theme

Selecting "Auto" synchronizes colors with your system's light/dark mode (automatically adapting to dark mode). Note: Claude Code only styles its own interactive CLI output, not the terminal app itself; adjust terminal styling in the terminal preferences. You can customize colors further, but choosing the right theme is a good start.

Note: on macOS, shortcut combinations using the Option key (such as Option+P to switch models) might fail natively. Map Option to the Meta key in terminal preferences (in iTerm2: Settings -> Profiles -> Keys, set left/right Option to "Esc+"). This was covered in Chapter 35. Vim users: setting the editor mode to vim via /config enables Vim keybindings in the input prompt.

💡 Summary in one sentence: Terminal settings resolve minor interactive annoyances—run /terminal-setup if newlines fail (universal fallback is Ctrl+J), set preferredNotifChannel to "terminal_bell" for alerts, and run /theme to select Auto matching your style; these three tweaks improve ergonomics.

---

06 Model Configuration: Selecting and Restricting Models

Finally, model configuration—affecting both capability and pricing. Chapter 04 and Chapter 06 covered API connections and billing; this section details how to select, switch, and save credits.

Selecting the Right Model for the Task

Claude Code supports multiple models with varying performance tiers and costs. The default might not be the most economical choice—running the most powerful model for simple tasks like correcting typos wastes API credits.

Analogy: Kitchen staffing—chef, line cook, apprentice. The head chef (Opus) yields premium results but carries high wages; assign complex tasks to them. The line cook (Sonnet) handles typical entrees and manages the daily volume. Prepping and washing ingredients is handled quickly and cheaply by the apprentice (Haiku). An efficient manager doesn't pay a head chef to wash vegetables—assigning tasks based on difficulty keeps operations profitable. Model configuration makes you that manager.

The CLI uses model aliases to abstract version numbers, including:

Alias	Target Model	Intended Workload
opus	Highest-tier Opus	Complex reasoning, system architectures, and hard bugs
sonnet	Latest Sonnet	Daily development and general programming tasks
haiku	Fast and economical Haiku	Simple operations and speed-sensitive chores
opusplan	Opus during planning, Sonnet during execution	Employs Opus to formulate steps in Plan Mode, switching to Sonnet to write code
default	Recommended default for your plan	Clears overrides and resets to default

The opusplan option balances capability and economics: it runs Opus during Plan Mode to construct a solution, automatically switching to Sonnet to execute code changes once approved. Hard logic burns Opus credits, while routine coding runs at Sonnet prices. For complex refactorings, opusplan provides high intelligence during design and economy during execution.

Aliases offer another advantage: they map to the provider's recommended version, updating automatically over time. Referencing opus automatically upgrades when a new version is released. If you require reproducible output across the team, specify the literal model ID instead (e.g., claude-opus-4-8).

How to Switch: Four Methods by Precedence

Configure models using these four approaches, from highest to lowest precedence:

# 1. Switch inside session (Instant override)
/model sonnet

# 2. Pass command line flag (Applies to this run only)
claude --model opus

# 3. Environment variables (Applies to current shell session)
export ANTHROPIC_MODEL=sonnet

// 4. Declare model field in settings.json (Persistent default)
{
  "model": "opusplan"
}

Rule of thumb: use /model for quick overrides, and write to the model field in settings.json to default to a selection (Chapter 31). Project and enterprise settings carry higher precedence, overriding personal settings—if you configure Opus but observe a different model running, verify project settings aren't forcing the default.

Tuning Thinking Effort

After choosing a model, you can adjust thinking effort—controlling depth. Running Opus can range from a "quick scan" to deep thinking, which directly affects credit usage.

Analogy: Quick prep vs. slow simmer. The same chef can adjust their focus based on requirements—whipping up quick dishes, or spending hours simmering a soup. Effort levels tune this focus. The SDK defines five options: low (faster, cheaper), medium (balanced scan), high (default for Opus 4.8/4.6 and Sonnet 4.6), xhigh (deeper scan, default for Opus 4.7), and max (deep thinking, higher credit cost).

Two practical patterns for effort control:

• Temporary Deep Scan: Add the keyword ultrathink anywhere in your prompt. This triggers deep thinking for this prompt run without changing session settings. Only the keyword ultrathink works; descriptive requests like "think carefully" do not alter effort.
• Persistent Effort: Run /effort inside the chat to select a level via slider, or set the effortLevel field in settings.json.

A helpful habit: keep the default level for daily work, appending ultrathink to prompts only when debugging complex logical bugs to analyze root causes. This is often cheaper than repeating queries.

Cost Controls: Restricting Models for the Team

If you manage a team, use availableModels to restrict which models members can select—e.g., allowlisting only Sonnet and Haiku while hiding Opus:

{
  "availableModels": ["sonnet", "haiku"]
}

Once configured, members cannot switch to unlisted models via /model, CLI flags, or environment variables. This is highly effective for cost controls. In budget-sensitive repositories, locking selection to Sonnet and removing Opus reduces credit spend; you can temporarily allowlist Opus when tackling difficult bugs.

💡 Summary in one sentence: Model configuration lets you allocate resources—delegate hard logic to opus, routine development to sonnet, minor tasks to haiku, and use opusplan for cost-efficient intelligence; switch models using /model and restrict team spend using availableModels in settings.json.

---

07 Practice: Configuring Sandbox and Restricting Models

Let's configure the sandbox and model restrictions to verify them. Run this on macOS, Linux, or WSL2; it is self-contained and avoids project configurations.

Step 1: Enable the Sandbox (inside the claude session)

/sandbox

Expected: The sandbox control panel opens. Select "Auto-allow" in the Mode tab. Seeing the panel means the sandbox is supported on your platform. If it shows a "Dependencies" tab (common on Linux/WSL2), it means bubblewrap or socat is missing; install them (sudo apt-get install bubblewrap socat) and restart the session.

Step 2: Run a sandboxed command to verify

Type inside the session (requesting a local file write):

create a sandbox-test.txt file in the current directory, writing a line hello sandbox inside

Expected: The command runs inside the sandbox without triggering permission prompts (since you enabled Auto-allow and it only writes locally—which is permitted). The file sandbox-test.txt is created. No prompts appearing confirms sandbox Auto-allow works. (Delete this file after verification.)

Step 3: Check the active model

/status

Expected: The /status panel displays the current plan and the active model. Note down which model it is running (e.g., Sonnet or Opus).

Step 4: Switch models and verify again

/model haiku

Expected: It reports switching to Haiku. Run /status again; the model field should show Haiku. The difference confirms /model took effect. Run /model sonnet or /model default to revert when done.

Step 5 (Optional): Set a default model

To default to a specific model in this repository, write to .claude/settings.json:

{
  "model": "sonnet"
}

Expected: Restarting claude in this project will run Sonnet by default (unless overridden via /model).

These steps walk you through: "enabling isolation -> verifying sandbox -> checking model -> switching model -> declaring defaults." Configuring other settings follows this same pattern: adjust options -> execute commands -> run /status to verify.

💡 Summary in one sentence: Verify the two most practical features—enable /sandbox Auto-allow to bypass prompts for local commands, and switch via /model checking changes with /status; always verify changes after configuration.

---

08 Summary

This article walked through the five key development configuration areas—in short, organizing Claude's workspace to improve ergonomics and safety.

Let's review the key configurations:

Configuration Area	How to Adjust It	Key Point
Sandbox	Run /sandbox, select Auto-allow	Restricts Bash only; file tools, MCP, and hooks run on host
Devcontainer	Add feature definition in devcontainer.json	Requires Docker; runs inside container, modifications sync locally
Network	Export HTTPS_PROXY and NODE_EXTRA_CA_CERTS	SOCKS proxies are unsupported; use proxy tunnels if domains are blocked
Terminal	Run /terminal-setup, /theme, or set notifications	Ctrl+J is the universal fallback for newlines
Model	Switch via /model or configure defaults in settings.json	opusplan balances capability/cost; availableModels restricts select options

You should now be able to: enable sandboxing to skip permission prompts, isolate untrusted repositories via containers, configure proxy routing and certificate trusts, fix newline bindings via /terminal-setup, and select models or set availableModels limits to manage credit usage. Tuning this workspace ensures Claude runs securely, ergonomically, and economically.

Recalling the manual monitoring scenario—running inside the sandbox or the web interface isolates execution, removing the need to monitor prompts manually. That is the value of development configurations: they keep you secure under the hood.

---

The next chapter 47 "Voice Mode" (experimental)—we tuned terminal ergonomics; the next explores a different input mechanism: voice. If your hands are occupied, being able to speak and say "refactor this function" frees up focus. Voice mode is an emerging feature; the next chapter introduces its capabilities.

---

Recommended Reading

• MCP: Connecting Claude to the External World
• Connecting Third-Party and Alternative Models
• Anti-Patterns: Common Misuse Cases