Claude Code Cloud Setup Guide (Vertex AI & Bedrock)

Guides
GenAI
LLM
Agentic coding
Cloud
GCP
AWS
Author

Chris Endemann

Published

February 15, 2026

Modified

March 12, 2026

This guide walks UW-Madison researchers and staff through setting up Claude Code with a cloud provider — either Google Vertex AI or Amazon Bedrock. It covers Windows and macOS, with provider-specific steps in tabs so you can follow whichever path matches your institutional account.

NoteThis guide reflects the author’s understanding as of the last date modified

AI tools, pricing, features, and contractual terms change frequently. This guide is community guidance, not official UW-Madison policy. For the latest institutional policies, data-use agreements, or questions about what data types are permitted with specific tools, consult UW-Madison Research Cyberinfrastructure or your department’s IT office.

TipNew to agentic coding?

See our companion guide, Claude Code Best Practices, for a broader introduction to agentic coding tools and how to use them effectively.

ImportantCLI only — cloud providers don’t work with the Desktop app or Web IDE

Vertex AI and Bedrock routing is only supported in the Claude Code CLI (terminal) and IDE extensions (VS Code, JetBrains). The Claude Desktop app (Code tab) and Web IDE require a direct Anthropic login (Max plan or API credits) — they cannot be configured to route through a cloud provider at this time. If you need the desktop GUI or web experience, you’ll need a separate Claude Max subscription. This guide covers the CLI path.

WarningUse caution with restricted or sensitive data

UW-Madison does not currently have a direct data-use or privacy agreement with Anthropic. While UW has agreements with cloud providers (Google, AWS, Microsoft) for their respective services, those agreements do not extend to Anthropic’s data handling — your prompts still reach Anthropic’s infrastructure for inference regardless of which cloud provider routes the request.

What this means in practice:

  • Do not use Claude Code with restricted data (HIPAA/PHI, FERPA, CUI, export-controlled, or data under a DUA that prohibits third-party processing) until a formal UW-Anthropic agreement is in place.
  • Avoid running Claude Code on machines where restricted data is stored. Even with sandboxing enabled, Claude can still read files outside your project directory — sandboxing only restricts writes. Anything Claude reads can be sent to Anthropic’s servers as part of a prompt. If you must run Claude Code on a machine with sensitive files, configure deny rules to block read access to sensitive paths (see Section 7) — but note that Read deny rules are best-effort and can be bypassed by allowed Bash commands like cat. The safest approach is to keep restricted data off machines where Claude Code runs.
  • Always enable sandboxing (Section 8) — it prevents unintended writes outside your project and adds network isolation. These are valuable protections even though read access isn’t fully restricted.
  • The web version offers the strongest isolation — each task runs in a fresh, ephemeral VM that can only access your cloned GitHub repo. It cannot reach your local filesystem, SSH keys, or other local resources, and storage is wiped when the task completes. This eliminates the local file-read risk entirely. However, the web version requires a paid Anthropic subscription (Pro $20/month through Max $200/month), which currently must be paid out of pocket — UW does not yet have institutional Anthropic billing in place.
  • For general/non-sensitive research code, cloud-routed Claude Code is fine to use today — your code is not used for model training under commercial terms, and telemetry is disabled by default for third-party providers.

UW-Madison is actively exploring institutional Anthropic licenses, credits, and data agreements to make this easier. We’ll update this guide as the situation evolves.

Why use a cloud provider instead of a direct subscription?

You can use Claude Code with a personal Claude Max subscription ($100–$200/month, unlimited usage) — no cloud setup required. So why go through the extra complexity of routing through a cloud provider?

What cloud providers give you:

  • Institutional billing and cost tracking — charges go to your UW-Madison cloud project, not your personal credit card. This matters for grant-funded research, shared lab budgets, and institutional procurement. UW-Madison has negotiated cloud discounts with both GCP and AWS, including reduced overhead on grants (26% vs 55.5% F&A) and NIH STRIDES pricing.
  • Enterprise security controls — both GCP and AWS let you manage IAM permissions, control network traffic, and audit API usage within your cloud project. Note that these controls govern access to your cloud resources — they do not change how Anthropic handles your data once it reaches their infrastructure.

What cloud providers do NOT change:

  • Your prompts still reach Anthropic’s infrastructure. Neither Vertex AI nor Bedrock runs the model inside your cloud project — your provider routes requests to Anthropic’s serving infrastructure. This means your data is processed by Anthropic regardless of which cloud provider you use.
  • UW’s cloud agreements don’t cover Anthropic’s data handling. UW-Madison has agreements with Google, AWS, and Microsoft for their respective services, but those agreements do not extend to Anthropic. There is no UW-Anthropic data-use agreement in place yet, so routing through a cloud provider does not give your data the same protections it would have for a native cloud service. See the warning above for practical guidance.
  • Data storage location is not controlled by your deployment choice. Anthropic stores data in the US, with processing distributed across multiple regions for reliability. If you need geographic control over where inference runs, that’s a separate data residency feature, not a cloud provider feature.
  • Training exclusion still applies. Under Anthropic’s commercial terms (including both Vertex AI and Bedrock), your prompts and outputs are not used for model training. This is a positive, but it is distinct from having a comprehensive data-use agreement. See Data Usage & Privacy for full details on retention, telemetry, and opt-outs.
Note

Bottom line: If you just want to try Claude Code personally, a Claude Max subscription is simpler and often cheaper for heavy individual use. Cloud providers make sense when you need institutional billing or enterprise security controls. However, neither approach currently provides UW-sanctioned data protections for restricted or sensitive data — UW is actively working toward an institutional Anthropic agreement. For now, avoid running Claude Code on machines that contain restricted data, since even sandboxing doesn’t prevent reads — and always enable sandboxing to at least restrict writes and network access. UW-Madison provisions both GCP and AWS accounts for research groups — running Claude Code through either provider is just one of many uses.

Already set up? Returning User Quick-Start

If you’ve already completed the full setup and just need to start a new session:

# If your credentials have expired (you'll get auth errors):
gcloud auth application-default login

# Navigate to your project and launch
cd ~/projects/my-project   # macOS / Linux / WSL2 (recommended for Windows)
# cd C:\Users\you\projects\my-project   # Windows PowerShell (no sandbox support)
claude
# If your credentials have expired (you'll get auth errors):
aws sso login --profile your-profile
# Or re-export your AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY

# Navigate to your project and launch
cd ~/projects/my-project   # macOS / Linux / WSL2 (recommended for Windows)
# cd C:\Users\you\projects\my-project   # Windows PowerShell (no sandbox support)
claude
Note

Windows users: For the best experience — including OS-level sandboxing — run Claude Code from WSL2 instead of PowerShell. Native Windows does not support sandboxing. If you haven’t set up WSL2 yet, see Section 8 — Sandboxing (Windows/WSL2) for a full walkthrough.

Once inside Claude Code:

/status       # Confirm your cloud provider is active and project/region are correct
/sandbox      # Enable sandboxing if not already persistent in settings
/cost         # Check token usage at any time during your session
Tip

Vertex AI: If you get 401/403 errors, re-run gcloud auth application-default login. If you get 404 “model not found” errors, check your region settings in ~/.claude/settings.json (see Section 5). If you get 429 “resource exhausted” errors, you need a quota increase (see Troubleshooting).

Bedrock: If you get AccessDeniedException, check your IAM permissions and ensure model access is enabled. If you get ValidationException: Model not found, verify your AWS_REGION and model IDs. If credentials expired, re-run aws sso login or refresh your access keys.

1. Prerequisites

Both platforms:

  • Internet connection
  • A UW-Madison GCP project with billing enabled (e.g., doit-rci-sandbox-gcp-baa4)
  • A UW-Madison AWS account with billing enabled
  • Windows 10 (build 1809+) or Windows 11
  • PowerShell (use this — not Git Bash, not CMD)
  • macOS 13.0 (Ventura) or later
  • Terminal (built-in) or any terminal emulator (iTerm2, Warp, etc.)

See the official Claude Code system requirements for the full list (OS versions, RAM, shell, etc.).

2. Install Claude Code

Official install docs: code.claude.com/docs/en/setup

Open PowerShell and run:

irm https://claude.ai/install.ps1 | iex
Warning

Do NOT use Git Bash (MINGW64) — the installer does not support it. Use PowerShell only.

After installation, you’ll likely see a message that C:\Users\<you>\.local\bin is not in your PATH. Fix this:

  1. Press Win + R, type sysdm.cpl, press Enter.
  2. Go to Advanced tab → Environment Variables.
  3. Under User variables, select Path → click Edit.
  4. Click New and add: C:\Users\<your-username>\.local\bin
  5. Click OK on all dialogs.
  6. Close and reopen PowerShell.

Verify:

claude --version

Open Terminal and run:

curl -fsSL https://claude.ai/install.sh | bash

Alternatively, if you use Homebrew:

brew install --cask claude-code

After installation, restart your terminal (or run source ~/.zshrc), then verify:

claude --version

The native installer places the binary at ~/.claude/bin/claude or ~/.local/bin/claude and updates your shell profile automatically. If claude isn’t found, ensure one of these paths is in your $PATH.

3. Install & Configure Your Cloud CLI

Official gcloud install docs: cloud.google.com/sdk/docs/install

Download and install the Google Cloud CLI for Windows. The installer adds gcloud to your PATH automatically.

Fix PowerShell Execution Policy (if needed):

If gcloud gives you a “running scripts is disabled” error:

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

Type Y to confirm.

If you’re running Claude Code from WSL2, you need gcloud installed inside your WSL2 environment (the Windows installation is not accessible from WSL2):

sudo apt-get install apt-transport-https ca-certificates gnupg curl
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee /etc/apt/sources.list.d/google-cloud-sdk.list
sudo apt-get update && sudo apt-get install google-cloud-cli

Option A — Homebrew (easiest):

brew install --cask google-cloud-sdk

Option B — Official installer:

curl https://sdk.cloud.google.com | bash

Then restart your terminal or run:

source ~/.zshrc   # or source ~/.bashrc

Authenticate (both platforms):

These commands are identical on both Windows and macOS:

# Log in with your UW-Madison Google account
gcloud auth login

# Set your GCP project
gcloud config set project YOUR-PROJECT-ID

# CRITICAL — this is what Claude Code actually uses to authenticate
gcloud auth application-default login

Both login commands open a browser window. Sign in with your UW-Madison email and grant the requested permissions.

Verify everything is configured correctly:

gcloud config list

You should see your UW-Madison email under [core] account and your project ID under [core] project.

Official AWS CLI install docs: docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

Download and run the AWS CLI MSI installer for Windows. The installer adds aws to your PATH automatically.

Verify:

aws --version

Option A — Homebrew (easiest):

brew install awscli

Option B — Official installer:

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /

Verify:

aws --version

Authenticate (both platforms):

Claude Code uses the standard AWS credential chain. Choose one of these methods:

Option A — AWS SSO (recommended for UW-Madison):

# Configure your SSO profile (one-time setup)
aws configure sso
# Follow the prompts: SSO start URL, region, account, role

# Log in (do this whenever credentials expire)
aws sso login --profile your-profile-name

Option B — IAM access keys:

aws configure
# Enter your AWS Access Key ID, Secret Access Key, and region

Option C — Environment variables:

export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
export AWS_REGION="us-east-1"
Tip

If your institution uses AWS SSO or federated identity, Option A is the most secure — no long-lived credentials on disk. Ask your UW-Madison AWS administrator which method your account uses.

4. Enable API Access & Request Models

Official Vertex AI setup: code.claude.com/docs/en/google-vertex-ai

Google’s Claude on Vertex docs: cloud.google.com/vertex-ai/generative-ai/docs/partner-models/claude

Enable the API:

gcloud services enable aiplatform.googleapis.com --project=YOUR-PROJECT-ID

Request access to Claude models:

  1. Go to the Vertex AI Model Garden in the GCP Console.
  2. Search for the Claude model you want (e.g., Claude Sonnet 4).
  3. Click the model card and complete the access request form.
  4. Approval may take minutes to a couple of days.

Verify IAM permissions:

Your GCP account needs the roles/aiplatform.user role (Vertex IAM docs), which includes:

  • aiplatform.endpoints.predict (model invocation)
  • aiplatform.endpoints.computeTokens (token counting)

If you don’t have this, ask your UW-Madison GCP administrator to grant it.

Official Bedrock setup: code.claude.com/docs/en/amazon-bedrock

AWS Bedrock model access docs: docs.aws.amazon.com/bedrock/latest/userguide/model-access.html

Enable model access:

  1. Open the Amazon Bedrock console and select your region (e.g., us-east-1).
  2. Go to Model catalog in the left sidebar.
  3. Find the Claude model you want (e.g., Claude Sonnet 4.6) and click Request model access.
  4. AWS will ask for a brief use-case description. A one-sentence explanation is sufficient. For most Claude models, approval is automatic and takes less than a minute.
Note

The first time you request access to Anthropic models on a new AWS account, you’ll need to complete a First Time Use (FTU) form with use-case details. This is a one-time per-account requirement.

Verify IAM permissions:

Your AWS identity needs permissions to invoke Bedrock models. At minimum, create (or ask your admin to attach) an IAM policy with:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:ListInferenceProfiles",
        "bedrock:ListFoundationModels"
      ],
      "Resource": "*"
    }
  ]
}

If your account uses AWS Marketplace for model access, you may also need aws-marketplace:Subscribe and aws-marketplace:ViewSubscriptions permissions.

5. Configure Claude Code

Edit (or create) your settings file at ~/.claude/settings.json.

Platform Full path
Windows (PowerShell) C:\Users\<your-username>\.claude\settings.json
Windows (WSL2) /home/<your-username>/.claude/settings.json
macOS /Users/<your-username>/.claude/settings.json
Important

WSL2 has its own home directory. If you set up Claude Code in both Windows PowerShell and WSL2, you need settings.json in both locations — they are completely separate filesystems. The Windows file at C:\Users\you\.claude\settings.json is not visible to WSL2. Similarly, gcloud must be installed and authenticated separately inside WSL2 (see Section 3).

{
  "model": "claude-sonnet-4-6",
  "autoUpdatesChannel": "latest",
  "env": {
    "CLAUDE_CODE_USE_VERTEX": "1",
    "CLOUD_ML_REGION": "global",
    "ANTHROPIC_VERTEX_PROJECT_ID": "YOUR-PROJECT-ID"
  },
  "sandbox": {
    "enabled": true
  }
}

Replace YOUR-PROJECT-ID with your actual GCP project ID (e.g., doit-rci-sandbox-gcp-baa4).

Region notes:

  • global is typically the cheapest and is a good default.
  • Not all models are available on the global endpoint. If you get 404 “model not found” errors, add region overrides for specific models by adding more entries to the env block:
"VERTEX_REGION_CLAUDE_3_5_HAIKU": "us-east5",
"VERTEX_REGION_CLAUDE_4_0_SONNET": "us-east5"
{
  "model": "claude-sonnet-4-6",
  "autoUpdatesChannel": "latest",
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "us-east-1",
    "AWS_PROFILE": "your-profile-name"
  },
  "sandbox": {
    "enabled": true
  }
}

Replace your-profile-name with your AWS CLI profile name (from aws configure sso or aws configure). If you’re using environment variables for credentials instead of a profile, omit AWS_PROFILE and set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in the env block.

Region notes:

  • us-east-1 has the broadest model availability and is a good default.
  • Not all models are available in all regions. Check the Bedrock model support by region page if you get “model not found” errors.

Model pinning (recommended):

Bedrock model aliases can change when new versions are released. To avoid surprises, pin specific model versions in your env block:

"ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-6",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-4-6",
"ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-haiku-4-5-20251001"
Warning

Do not include // comments in settings.json. The examples elsewhere in this guide use jsonc syntax for readability, but settings.json is parsed as plain JSON, which does not support comments. If you copy-paste a block with comments, Claude Code will report “Invalid or malformed JSON” in claude doctor.

The model field sets your default model — claude-sonnet-4-6 is a good balance of cost and capability. Change it to claude-opus-4-6 if you need maximum reasoning power (at higher cost).

ImportantSandbox platform prerequisites

The sandbox config above enables OS-level isolation that restricts Claude’s bash commands to your project directory. It works out of the box on macOS (uses Apple’s Seatbelt). On Linux/WSL2, you must first install bubblewrap and socat — see Section 8 for step-by-step instructions including how to verify you’re on WSL2 (WSL1 is not supported). Native Windows (PowerShell) does not yet support sandboxing — the setting will be ignored, so leave it in place for when support arrives. See Section 8 for full configuration details.

6. Verify the Setup

Run these in your terminal (PowerShell on Windows, Terminal on macOS):

claude --version
claude doctor

Then launch Claude Code from a project directory:

cd C:\Users\you\projects\my-project
claude
cd ~/projects/my-project
claude

On first launch, Claude Code will present a login method selection screen. Since you’re using a 3rd-party cloud provider, select option 3 (“3rd-party platform”) and then choose your provider (e.g., Vertex AI) when prompted. Claude Code will detect your cloud credentials automatically — no API key is needed.

Once inside Claude Code, run /status to confirm your provider is active:

API provider: Google Vertex AI
GCP project: your-project-id
Default region: global
API provider: Amazon Bedrock
AWS region: us-east-1
Note

When using either cloud provider, the /login and /logout commands are disabled — authentication is handled entirely through your cloud CLI credentials (gcloud or aws).

7. Filesystem Safety & Permissions

Official permissions docs: code.claude.com/docs/en/permissions

Sandboxing docs: code.claude.com/docs/en/sandboxing

Understand the risk before you start

WarningClaude Code runs with your user’s full filesystem permissions

This is the single most important thing to understand before using it.

When you launch Claude Code from the CLI, it has access to your current working directory — but it is not strictly confined to it. Without sandboxing enabled, Claude can read, modify, create, or delete files anywhere your user account has access, including parent directories, your home folder, and system files. Independent testing has confirmed that without sandboxing, Claude can create files in parent directories above the working directory without any special prompt.

This means a poorly worded prompt, an agentic loop, or a prompt injection attack embedded in a file Claude reads could cause changes in places you didn’t intend.

Practical recommendations:

  • Avoid running Claude Code on machines where restricted or sensitive data is stored. Sandboxing restricts writes but not reads — Claude can still read files anywhere on the machine and send their contents to Anthropic’s servers as part of a prompt. UW does not yet have a data-use agreement with Anthropic (see warning above), so even cloud-routed usage sends your prompts to Anthropic’s infrastructure.
  • If you must run on a machine with sensitive files, add deny rules (see below) to block read access to sensitive paths. But note that Read deny rules are best-effort — allowed Bash commands like cat can still read denied files. Denying both Read and the relevant Bash patterns together provides stronger protection (see this security deep-dive for details).
  • Test only within isolated Git repositories, with no sensitive data present in the local repo.
  • Always enable sandboxing (Section 8) — it restricts writes to your project directory and adds network isolation at the OS level. It’s available on macOS (built-in) and Linux/WSL2 (requires bubblewrap). Native Windows does not yet support it.

Always launch from your project directory

cd C:\Users\you\projects\my-project
claude
cd ~/projects/my-project
claude

Claude Code defaults to operating in the directory where it’s launched. Starting from C:\ or / or your home directory gives it an unnecessarily broad scope.

Use Git as your safety net

Always work inside a Git repository. This is your most important protection:

  • You can instantly see what changed with git diff.
  • You can revert any unwanted changes with git checkout . or git stash.
  • Claude Code itself is Git-aware and will generally respect repository boundaries.

Before starting a Claude Code session, make sure your working tree is clean (commit or stash pending changes). That way, anything Claude does can be cleanly reviewed or rolled back.

Use the default permission mode

Out of the box, Claude Code asks for your approval before running most commands. Do not change this unless you understand the implications. Specifically:

  • Do NOT use --dangerously-skip-permissions unless you’re in an isolated container/VM. This flag bypasses all safety checks.
  • Do NOT set the mode to bypassPermissions in settings.

Understand how permissions actually work

In the default mode, Claude Code already asks for your approval before running most commands that modify your system (file writes, bash commands, network requests, etc.). Read-only operations like viewing files generally run without prompting.

You can customize this behavior with three types of rules in settings.json:

  • deny — Hard block. Claude cannot use the tool, period. You won’t even be asked. Deny rules always win over allow rules.
  • allow — Auto-approve. Claude can use the tool without asking you first. This is a convenience shortcut — it skips the approval prompt for things you trust.
  • ask — Force a prompt, even if something else would auto-approve it.

You do NOT need to add allow rules for Claude Code to work. Without any custom rules, it will simply ask you to approve each action as it comes up. The default behavior is already safe — deny rules are the ones that add protection, while allow rules just reduce the number of prompts you see.

Add deny rules to protect sensitive areas

Add a permissions block to your ~/.claude/settings.json file (the same file you edited in Section 5). Think of deny rules as guardrails — they block Claude from accessing sensitive paths regardless of what it tries to do.

These examples block: SSH keys, .env files, cloud credentials (~/.config/gcloud/ and ~/.aws/), destructive commands (rm -rf), and network tools (curl, wget). Replace endemann with your actual username before pasting into settings.json.

Warning

settings.json is plain JSON — no comments allowed. The blocks below are ready to copy-paste. Do not add // comments or Claude Code will report “Invalid or malformed JSON” in claude doctor.

Home directory is /Users/endemann. Run whoami to check your username.

{
  "permissions": {
    "deny": [
      "Read(//Users/endemann/.ssh/**)",
      "Edit(//Users/endemann/.ssh/**)",
      "Read(//Users/endemann/.env)",
      "Edit(//Users/endemann/.env)",
      "Read(//Users/endemann/.config/gcloud/**)",
      "Edit(//Users/endemann/.config/gcloud/**)",
      "Read(//Users/endemann/.aws/**)",
      "Edit(//Users/endemann/.aws/**)",
      "Bash(rm -rf *)",
      "Bash(curl:*)",
      "Bash(wget:*)"
    ]
  }
}

Home directory is C:\Users\endemann. Run echo $env:USERNAME to check your username. Note: use forward slashes in permission rules, even on Windows.

{
  "permissions": {
    "deny": [
      "Read(//C:/Users/endemann/.ssh/**)",
      "Edit(//C:/Users/endemann/.ssh/**)",
      "Read(//C:/Users/endemann/.env)",
      "Edit(//C:/Users/endemann/.env)",
      "Read(//C:/Users/endemann/.config/gcloud/**)",
      "Edit(//C:/Users/endemann/.config/gcloud/**)",
      "Read(//C:/Users/endemann/.aws/**)",
      "Edit(//C:/Users/endemann/.aws/**)",
      "Bash(rm -rf *)",
      "Bash(curl:*)",
      "Bash(wget:*)"
    ]
  }
}

Home directory is /home/endemann. Run whoami to check your username.

{
  "permissions": {
    "deny": [
      "Read(//home/endemann/.ssh/**)",
      "Edit(//home/endemann/.ssh/**)",
      "Read(//home/endemann/.env)",
      "Edit(//home/endemann/.env)",
      "Read(//home/endemann/.config/gcloud/**)",
      "Edit(//home/endemann/.config/gcloud/**)",
      "Read(//home/endemann/.aws/**)",
      "Edit(//home/endemann/.aws/**)",
      "Bash(rm -rf *)",
      "Bash(curl:*)",
      "Bash(wget:*)"
    ]
  }
}
Tip

The // prefix in permission rules means “absolute path from the filesystem root” — there is no ~/ shorthand. That’s why you need the full path like //Users/endemann/ rather than ~/.ssh/.

Note

Why not just rely on the approval prompt? Because deny rules are absolute — they work even if you accidentally click “allow” or “always allow” on a prompt. They also protect against prompt injection attacks where malicious content in a file tricks Claude into running something harmful. The approval prompt is your first line of defense; deny rules are the backup that can’t be bypassed.

Important caveat: Read deny rules apply on a “best-effort” basis to built-in tools like Grep and Glob. However, if a Bash command (like cat .env) is allowed, it can still read the file. This is why denying both Read and the relevant Bash commands together gives stronger protection. See this security deep-dive for details.

Add allow rules to reduce prompt fatigue

These also go in ~/.claude/settings.json, inside the same permissions block as your deny rules. By default, Claude Code asks “Do you want to proceed?” before every file write, shell command, and git operation. This gets old fast — in a typical session you might approve the same git add, git commit, and git push sequence a dozen times. You can add allow rules so Claude runs trusted commands without asking:

Minimal — just stop the git and test prompts:

{
  "permissions": {
    "allow": [
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git push *)",
      "Bash(git checkout *)",
      "Bash(git log *)",
      "Bash(git diff *)",
      "Bash(git status)",
      "Bash(git rm *)",
      "Bash(gh *)",
      "Bash(python *)",
      "Bash(pytest *)"
    ]
  }
}

More aggressive — also auto-approve file edits:

{
  "permissions": {
    "allow": [
      "Edit",
      "Write",
      "Bash(git *)",
      "Bash(gh *)",
      "Bash(python *)",
      "Bash(pytest *)",
      "Bash(npm *)",
      "Bash(pip *)"
    ]
  }
}
TipThe fastest way: use acceptEdits mode or enable sandboxing

Instead of listing individual allow rules, you can:

  • Switch to acceptEdits mode (Shift+Tab inside a session) — auto-approves all file edits while still prompting for bash commands.
  • Enable sandboxing (see Section 8) — this is the best option. Sandboxing auto-approves bash commands that stay within your project directory at the OS level, while actually increasing security.
  • Use the interactive prompt — when Claude asks “Do you want to proceed?”, select “Yes, and don’t ask again for [command pattern]” to build up your allow list organically during a session.

You don’t have to add any allow rules — the default “ask before doing” behavior is safe, especially when you’re starting out. But if you find yourself mindlessly hitting “Yes” on every prompt, that’s a sign you should either add allow rules or enable sandboxing.

Check your current permissions

Run /permissions inside a Claude Code session at any time to see what rules are active and which settings file they came from. This is especially helpful to verify your deny rules are loaded correctly.

Use project-level settings for shared repos

Claude Code reads two settings files, and merges them:

File Scope What to put here
~/.claude/settings.json User-level — applies to every project you open Personal deny rules (SSH keys, cloud creds, .env), model choice, sandbox config
<project-root>/.claude/settings.json Project-level — applies only when Claude Code is launched inside this repo Repo-specific deny rules (e.g., don’t read secrets/), shared team guardrails

How merging works: Claude Code combines both files. If either file denies something, it’s denied — project-level deny rules apply to everyone, even if their personal settings are more permissive. You don’t have to choose one or the other; most teams use both.

The project-level file lives inside your Git repo, so you can commit it and every collaborator automatically inherits the same rules:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl:*)",
      "Bash(wget:*)"
    ]
  }
}
Note

Path syntax: Paths starting with // are absolute (used in user-level settings to protect home-directory files like ~/.ssh/). Paths starting with ./ are relative to the project root (used in project-level settings). Use ** to match recursively. See the permission rules reference for full pattern syntax.

Interactive safeguards during a session

  • Press Esc at any time to interrupt Claude Code mid-operation.
  • Press Shift+Tab to cycle through permission modes during a session.
  • Use /permissions to view and manage active permissions.
  • Review every command before approving it — especially rm, mv, file writes outside your project, and anything involving sudo.

Permission mode cheat sheet

Mode What it does When to use it
default Asks before most operations Day-to-day work (recommended)
acceptEdits Auto-approves file edits, still asks for bash commands Trusted refactoring tasks
plan Read-only, no modifications allowed Exploring a codebase, code review
dontAsk Auto-denies anything not explicitly in allow list Strict automation
bypassPermissions Skips ALL checks Isolated containers only — never on your local machine

8. Sandboxing (Strongly Recommended)

Tip

If you followed Section 5, sandboxing is already enabled in your settings.json. This section covers platform prerequisites, how to choose a sandbox mode, and what sandboxing actually does.

Sandboxing is the strongest protection available against Claude modifying files outside your project. It uses OS-level enforcement (not just Claude’s own judgment) to restrict what bash commands can access — even if a prompt injection bypasses Claude’s decision-making.

What sandboxing does (official docs):

  • Filesystem isolation: Write access is restricted to the current working directory and its subdirectories — Claude cannot modify, create, or delete files outside your project directory. This is enforced at the OS kernel level. However, Claude can still read files anywhere on the machine (unless blocked by deny rules), and anything it reads can be included in prompts sent to Anthropic’s servers. This is an important limitation — sandboxing alone is not sufficient to protect sensitive data that exists elsewhere on the same machine.
  • Network isolation: Only approved domains can be accessed. New domain requests trigger a permission prompt. This prevents data exfiltration even if Claude is compromised.

Add these deny rules to your ~/.claude/settings.json to prevent Claude from reading files outside your project:

{
  "permissions": {
    "deny": [
      "Read(//**)",
      "Read(~/**)",
      "Bash(cat:*)"
    ]
  }
}
  • Read(//**) — blocks the Read tool from accessing any file via an absolute path (files inside your project use relative paths and are unaffected)
  • Read(~/**) — blocks reads via home directory paths
  • Bash(cat:*) — blocks the most common Bash bypass for Read deny rules

Caveats: Read deny rules are best-effort for built-in tools like Grep and Glob. Other Bash commands beyond cat (e.g., head, tail, less) could also read files — add deny rules for those too if needed. For more granular deny rules targeting specific sensitive paths (SSH keys, cloud credentials, .env files), see Section 7.

Without sandboxing, these protections do not exist — Claude operates with your full user permissions, and can create/modify files in parent directories without any special prompt.

Anthropic reports that sandboxing reduces permission prompts by 84% while increasing security — you get fewer interruptions and better protection.

How to enable it:

Works out of the box using Apple’s Seatbelt framework. Inside a Claude Code session, run:

/sandbox

Choose “Auto-allow mode” (recommended) — sandboxed commands run automatically without permission prompts, while anything that would exceed the sandbox boundaries falls back to the normal approval flow.

WSL2 uses bubblewrap for sandbox isolation — the same mechanism used on native Linux. WSL1 is not supported because bubblewrap requires kernel features only available in WSL2.

Step 1 — Confirm you’re on WSL2:

Open a Windows PowerShell window (not your WSL terminal) and run:

wsl -l -v

You should see VERSION 2 next to your distribution. If you’re on WSL1, upgrade to WSL2 first. Once confirmed, open your WSL2 terminal — all remaining steps run inside WSL.

Step 2 — Install Claude Code inside WSL2:

WSL2 is a separate Linux environment — your Windows PowerShell installation of Claude Code doesn’t carry over. Inside your WSL2 terminal, install it with npm:

npm install -g @anthropic-ai/claude-code

You’ll also need to reconfigure your cloud CLI credentials inside WSL2, since it has its own filesystem and config:

gcloud auth login
gcloud auth application-default login
gcloud config set project YOUR_PROJECT_ID
aws configure
# Enter your Access Key ID, Secret Access Key, and default region when prompted

Verify both are working:

claude --version

Step 3 — Copy your settings into WSL2:

WSL2 has its own home directory (/home/<you>/), completely separate from Windows (C:\Users\<you>\). Claude Code won’t see your Windows settings.json — you need a copy inside WSL2:

# Create the config directory if it doesn't exist
mkdir -p ~/.claude

# Copy your Windows settings into WSL2
cp /mnt/c/Users/$(cmd.exe /C "echo %USERNAME%" 2>/dev/null | tr -d '\r')/.claude/settings.json ~/.claude/settings.json

Or if you prefer, create ~/.claude/settings.json manually with the same content you used in Section 5 (use nano ~/.claude/settings.json).

Verify the settings look correct:

cat ~/.claude/settings.json

Step 4 — Install sandbox dependencies:

# Ubuntu/Debian (most common WSL distro)
sudo apt-get update && sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

Step 5 — Launch Claude Code and enable sandboxing:

cd ~/projects/my-project   # navigate to your project first
claude                      # launch Claude Code

Then inside the Claude Code session, run:

/sandbox

Choose “Auto-allow mode” — sandboxed commands run automatically, while anything outside sandbox boundaries falls back to the normal approval flow.

Step 5 — Verify it’s working:

After enabling, Claude’s bash commands should run without permission prompts as long as they stay within your project directory. If a command needs to write outside the project or access a new network domain, you’ll still get a prompt.

Tip

If you need tools like npm, pip, or kubectl to write outside your project directory (e.g., to ~/.npm or ~/.kube), grant specific write access in your settings.json:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.npm", "~/.kube", "//tmp"]
    }
  }
}

Path prefixes: // = absolute path, ~/ = home directory, / = relative to settings file. See the official sandboxing docs for full path syntax.

Sandboxing is not yet supported on native Windows. Use deny rules and allow rules as your primary protection. If you need stronger isolation, consider running Claude Code from WSL2 instead.

Sandbox modes explained:

Mode Behavior Best for
Auto-allow Sandboxed commands run without prompts. Commands that exceed sandbox boundaries fall back to normal approval flow. Day-to-day work — fewer interruptions, same security
Regular permissions All commands go through standard approval, even when sandboxed. When you want to review every command regardless

In both modes, the OS-level filesystem and network restrictions are identical. The only difference is whether sandboxed commands are auto-approved.

Note

Sandboxing applies only to Bash commands and their child processes. The built-in Read/Edit tools are governed by permission rules. Use both together for the strongest security posture — this is what Anthropic calls “defense in depth”.

Some tools are incompatible with sandboxing (e.g., docker, watchman). If a tool fails inside the sandbox, you can exclude it with "excludedCommands" in your sandbox settings so it runs outside the sandbox with normal permission prompts instead.

Further reading on permissions & security

9. Billing, Cost Management & Avoiding Runaway Costs

Official cost management docs: code.claude.com/docs/en/costs

WarningClaude Code on cloud providers is pay-as-you-go

Every token you send and receive is billed to your cloud project. Unlike a Claude Pro/Max subscription with fixed monthly pricing, there is no spending cap unless you set one up yourself. You can rack up significant charges quickly if you’re not careful.

Typical costs to expect

According to Anthropic’s own documentation, the average Claude Code session costs about $6 per developer per day, with 90% of users staying under $12/day. However, this is an average — complex tasks, long sessions, or agentic loops can blow past this easily. Monthly costs with Sonnet typically run $100–$200/developer, but there’s large variance.

Use the /cost command inside Claude Code at any time to see your current session’s token usage and estimated cost:

/cost

Understand what drives costs

Token costs scale with context size — the more context Claude processes, the more you pay. Key cost drivers:

  • Long conversations: Claude re-processes the entire conversation history with each message. A session that’s been going for hours costs more per-message than a fresh one.
  • Large codebases: If Claude reads many files to understand your project, that’s all input tokens.
  • Extended thinking: Enabled by default with a budget of ~32K tokens. Thinking tokens are billed as output tokens (the expensive kind). For simple tasks, this is overkill.
  • Agentic loops (see below): The single biggest risk for runaway costs.

Agentic loops — the #1 cost risk

Warning

An agentic loop happens when Claude gets stuck in a cycle — repeatedly reading the same files, running the same commands, or auto-compacting and re-expanding its context. This can burn through tokens at an alarming rate.

Real-world examples from the community:

  • One user reported a bug where an auto-compacting loop consumed 108 million tokens in a single day ($64–$78), compared to their normal 12–68M tokens/day.
  • Runaway spikes of $235+ over a 4-day period were documented from that same loop bug.
  • Version updates have occasionally caused 4x faster token consumption on the same tasks.

How to protect yourself:

  • Watch for signs: If Claude seems to be reading the same files over and over, or your /cost jumps unusually fast, press Esc immediately to interrupt.
  • Use /compact to compress long conversations before they bloat.
  • Use /clear when switching to unrelated tasks — don’t let stale context accumulate.
  • Be specific in prompts. Vague requests like “improve this codebase” trigger broad scanning. “Add input validation to the login function in auth.ts” is much cheaper.
  • Use plan mode (Shift+Tab) before expensive operations. Claude outlines its approach for your approval before writing code, preventing costly rework.
  • Start with Sonnet, not Opus. Only escalate to Opus for genuinely complex reasoning tasks. Opus costs significantly more per token.

Set up budget alerts (do this NOW)

Budget alerts won’t automatically stop spending, but they’ll email you when you’re approaching a threshold. Set this up before your first Claude Code session.

GCP budget alerts: cloud.google.com/billing/docs/how-to/budgets

  1. Go to Billing → Budgets & Alerts in the GCP Console.
  2. Click Create Budget.
  3. Scope it to your project (e.g., doit-rci-sandbox-gcp-baa4).
  4. Set a monthly budget amount you’re comfortable with (e.g., $50, $100, $200).
  5. Set alert thresholds at 50%, 80%, and 100% of your budget.
  6. Add your email as a notification recipient.
Important

Budget alerts are notifications only — they do NOT automatically stop your services or disable billing. If you hit 100% of your budget at 2 AM, charges will continue until you manually intervene. Check your billing console daily.

Set quota limits as a hard ceiling:

Unlike budget alerts, quotas can actually stop usage. Go to Quotas & System Limits and set reasonable TPM (tokens per minute) quotas for the Claude models you’re using. If you hit your quota, Claude Code will get 429 errors instead of running up your bill.

AWS Budgets docs: docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html

  1. Go to AWS Budgets in the AWS Console.
  2. Click Create budget.
  3. Choose Cost budget and set a monthly amount (e.g., $50, $100, $200).
  4. Add alert thresholds at 50%, 80%, and 100% of your budget.
  5. Add your email as a notification recipient.
Important

Like GCP, AWS budget alerts are notifications only by default — they do NOT automatically stop your services. However, AWS does support budget actions that can automatically restrict IAM permissions when a threshold is hit. Consider setting up an action to revoke bedrock:InvokeModel at 100% of budget as a hard stop.

Bedrock quotas:

Bedrock enforces per-model quotas on RPM (requests per minute) and TPM (tokens per minute). Default quotas are relatively low (e.g., 25 RPM for Opus). View and request increases at Service Quotas → Amazon Bedrock in the AWS Console.

Check your billing console daily

Make it a habit to check your cloud billing daily while actively using Claude Code. Look for:

  • Unexpected spikes in AI/ML charges
  • Daily costs that exceed your expectations
  • Any charges from services you didn’t intentionally use

Cost-saving tips

Strategy Savings
Use Sonnet instead of Opus for routine tasks Significantly lower per-token cost
Run /clear between unrelated tasks Avoids paying to re-process old context
Run /compact during long sessions Compresses context, reduces per-message cost
Lower extended thinking budget (MAX_THINKING_TOKENS=8000) Reduces output token costs on simple tasks
Keep your CLAUDE.md files lean (<500 lines) Less context loaded on every message
Use plan mode before big refactors Catches wrong approaches before expensive execution
Disable non-essential model calls DISABLE_NON_ESSENTIAL_MODEL_CALLS=1 in env

Pricing reference

For the latest Claude model pricing, see:

Note

On Vertex AI, the token usage shown on the GCP Quotas page may be inaccurate for Claude models due to estimation and refund logic. For accurate billing, check the GCP Billing Reports page or use /cost inside Claude Code.

9. Data Usage & Privacy

Official data usage docs: code.claude.com/docs/en/data-usage

Training policy

Whether your code is used for model training depends on your account type:

Account type Used for training?
API, Vertex AI, Bedrock, Foundry (commercial) No — Anthropic does not train on your prompts or outputs unless you explicitly opt in (e.g., the Development Partner Program)
Team & Enterprise (commercial) No — same commercial terms
Free, Pro, Max (consumer) Opt-in — you choose whether to allow training at claude.ai/settings/data-privacy-controls

If you’re accessing Claude Code through a UW-Madison cloud account (Vertex AI or Bedrock), your usage falls under Anthropic’s commercial terms — your code is not used for training. However, note that UW-Madison does not yet have a direct data-use agreement with Anthropic. The no-training guarantee comes from Anthropic’s standard commercial terms, not from a UW-negotiated agreement. This distinction matters for restricted or regulated data — see the data sensitivity warning at the top of this guide.

Note

Important nuances for consumer plans (Free/Pro/Max):

  • Safety exception: Even with training disabled, conversations flagged for safety review may be used to improve Anthropic’s safety systems (e.g., training safeguard models).
  • What’s included: The entire conversation — prompts, outputs, custom styles, and conversation preferences.
  • What’s excluded: Raw content from connectors (Google Drive, MCP servers) is not included, unless you directly copy that content into your conversation.
  • Feedback (thumbs up/down): Submitting feedback stores the full related conversation for up to 5 years (de-linked from your user ID). This data may be used for training regardless of your training setting.

Data retention

Account type Retention period
API / Vertex AI / Bedrock / Team / Enterprise 30 days (default)
Enterprise with Zero Data Retention (ZDR) 0 days (must be enabled per organization)
Consumer — training allowed 5 years
Consumer — training not allowed 30 days

Claude Code also caches sessions locally on your machine for up to 30 days to enable session resumption (configurable).

Telemetry and error reporting

Claude Code sends operational metrics and error reports by default when using the direct Claude API:

Service What it sends Opt-out
Statsig (metrics) Latency, reliability, usage patterns — no code or file paths DISABLE_TELEMETRY=1
Sentry (errors) Error logs — no code or file paths DISABLE_ERROR_REPORTING=1
/bug command Full conversation history including code (only when you run /bug) DISABLE_BUG_COMMAND=1
Session quality surveys Numeric rating only (1/2/3/dismiss) — no conversation data CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1
Tip

Using Vertex AI, Bedrock, or Foundry? All non-essential traffic (telemetry, error reporting, /bug, surveys) is disabled by default for third-party providers. You don’t need to set any environment variables.

To disable everything at once regardless of provider, set CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1. Environment variables can be set in your settings.json.

10. Troubleshooting

“model not found” (404):

The model may not be available on the global endpoint. Try changing your region:

"CLOUD_ML_REGION": "us-east5"

Or add a model-specific override (see Section 5).

429 “Resource Exhausted”:

You need a quota increase. Go to Cloud Console → Quotas, filter by the Claude model, and request an increase.

Permission denied / IAM errors:

Ask your UW-Madison GCP admin to ensure you have the roles/aiplatform.user role on the project.

gcloud command not found:

Make sure the Google Cloud SDK is installed and restart PowerShell.

If you installed via Homebrew, run source "$(brew --prefix)/share/google-cloud-sdk/path.zsh.inc" or restart your terminal. If you used the curl installer, make sure you ran source ~/.zshrc after install.

Authentication expired:

Re-run (both platforms):

gcloud auth application-default login

AccessDeniedException:

Your IAM user/role doesn’t have the required Bedrock permissions. Ensure your policy includes bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream. See Section 4 for the full policy.

ValidationException: Model not found:

Check that: (1) you’ve enabled model access for the specific Claude model in the Bedrock console, (2) your AWS_REGION is set to a region where the model is available, and (3) your model ID is correct. Try us-east-1 if unsure.

ResourceNotFoundException:

You haven’t completed model access approval. Go to the Bedrock Model catalog and request access.

429 “ThrottlingException”:

You’ve hit your Bedrock quota. Request an increase at Service Quotas → Amazon Bedrock. Default quotas are low (e.g., 25 RPM for Opus).

aws command not found:

Make sure the AWS CLI is installed and restart PowerShell.

If you installed via Homebrew, restart your terminal. If you used the pkg installer, ensure /usr/local/bin is in your $PATH.

Credentials expired (SSO):

Re-run:

aws sso login --profile your-profile-name
Tip

Claude Code supports automatic credential refresh for AWS SSO. Configure awsAuthRefresh in your settings so Claude Code automatically re-authenticates when credentials expire mid-session, instead of failing with auth errors.

Common issues (both providers)

claude command not found:

Ensure C:\Users\<you>\.local\bin is in your user PATH (see Section 2). Restart PowerShell after editing PATH.

Ensure ~/.claude/bin or ~/.local/bin is in your $PATH. Restart your terminal or run source ~/.zshrc.

Run diagnostics:

claude doctor

This checks your installation, authentication, and configuration for common issues.

11. Quick Reference

# Install Claude Code
irm https://claude.ai/install.ps1 | iex

# Install gcloud (if needed)
# Download from https://cloud.google.com/sdk/docs/install

# Authenticate with GCP
gcloud auth login
gcloud auth application-default login

# Launch Claude Code
cd C:\your\project
claude
# Install Claude Code
curl -fsSL https://claude.ai/install.sh | bash
# or: brew install --cask claude-code

# Install gcloud (if needed)
brew install --cask google-cloud-sdk
# or: curl https://sdk.cloud.google.com | bash

# Authenticate with GCP
gcloud auth login
gcloud auth application-default login

# Launch Claude Code
cd ~/your/project
claude
# Install Claude Code
irm https://claude.ai/install.ps1 | iex

# Install AWS CLI (if needed)
# Download from https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

# Authenticate with AWS
aws sso login --profile your-profile
# or: aws configure

# Launch Claude Code
cd C:\your\project
claude
# Install Claude Code
curl -fsSL https://claude.ai/install.sh | bash
# or: brew install --cask claude-code

# Install AWS CLI (if needed)
brew install awscli

# Authenticate with AWS
aws sso login --profile your-profile
# or: aws configure

# Launch Claude Code
cd ~/your/project
claude

In-session commands (all providers)

/status        # Confirm your cloud provider is active
/cost          # Check current session token usage and cost
/compact       # Compress conversation context to save tokens
/clear         # Wipe context when switching tasks
/permissions   # View and manage active permission rules
/sandbox       # Check or enable OS-level sandboxing
Esc            # Interrupt Claude mid-operation
Shift+Tab      # Cycle through permission modes

Further Reading