AWS Builder Center

Builder Center

Configuring Claude Cowork with Amazon Bedrock

Configuring Claude Cowork with Amazon Bedrock

A macOS walkthrough for configuring Claude Cowork on Amazon Bedrock (research preview) — full desktop Claude, inference inside your own AWS account.

Jason Salcido

If you want to use Claude but keep inference inside your own AWS account — for data governance, compliance, billing consolidation, regional control, or just to stay inside the security boundary your organization already trusts — Amazon Bedrock is the path. Until recently, that path only got you Claude Code: a powerful coding agent, but not the general-purpose desktop experience many users want. With the recent  announcement of Claude Cowork on Amazon Bedrock , that's no longer the case.
This post walks through configuring Cowork against Bedrock on macOS, with the lessons I picked up along the way.

What is Claude Cowork

With Claude Cowork, your users can delegate research, document analysis, data processing, and report generation to Claude from a desktop application. They get the core Claude Desktop capabilities including projects, artifacts, memory, file upload and export, remote connectors, skills, plugins, and MCP servers. Features that require Anthropic-hosted inference, including the Chat tab, Computer Use, and the Skills Marketplace, are not included because Claude Cowork routes model inference exclusively through Amazon Bedrock in your AWS account. For a full feature comparison with Claude Enterprise, see Features on 3P.
Note: Cowork's third-party inference support is a preview feature. The configuration UI and file format will continue to evolve — keep an eye on the  Cowork 3P configuration reference  and the  Claude on AWS product page .

How third-party config is meant to work

In a production rollout, third-party inference configuration is expected to be managed by an enterprise device-management tool (MDM) that pushes a signed configuration to each endpoint. That's the long-term model: admins define the Bedrock region, allowed models, MCP servers, and egress rules centrally, and users just launch the app.
During the preview, you can also enable Developer Mode in the desktop app to access the same configuration directly on your own machine. That's the path this post covers — how to set Cowork up yourself, today, on macOS.

Two config files to know about

Cowork on 3P uses two separate JSON config files on macOS, and it matters which one you edit depending on what you're configuring. Getting these straight up front saves a lot of head-scratching:
File
Path
Purpose
3P managed config
~/Library/Application Support/Claude-3p/configLibrary/<uuid>.json
Admin/enterprise configuration: inference provider, models, managed MCP servers, egress allow-lists, telemetry settings. In a production deployment, MDM pushes this file. In developer mode, you edit it yourself.
Desktop user config
~/Library/Application Support/Claude-3p/claude_desktop_config.json
User-scoped configuration, primarily the mcpServers block for local stdio MCPs you add for personal use (the same format Claude Desktop has always used).
The 3P managed config file lives under a UUID filename, so it's worth symlinking to somewhere more memorable. Throughout this post, I'll refer to the symlinked path  ~/.claude/cowork-3p-config.json :
Bash
ln -s "/Users/you/Library/Application Support/Claude-3p/configLibrary/<uuid>.json" \
      ~/.claude/cowork-3p-config.json

To find the  <uuid>  filename, use the Reveal in Finder option inside the 3P config window — it takes you straight to the file.
Quick rule of thumb:
  • Adding a personal local MCP server? →  claude_desktop_config.json 
  • Adding an enterprise-managed MCP server with permission policy? → 3P managed config ( ~/.claude/cowork-3p-config.json )
  • Configuring inference, models, egress, telemetry? → 3P managed config
Warning: Always quit Cowork fully (Cmd+Q) before editing either file. The app may overwrite your changes on quit if it's still running.

Before you start

A few things to have ready:
  • Bedrock access in the region you want to use. Global inference profiles (for example, the  global.anthropic.claude-*  family) remove a lot of cross-region routing headaches.
  • An authentication method for Bedrock. You can use a Bedrock API key (bearer token), or an AWS CLI profile. If you go the profile route, make sure it's configured locally and — if it's an SSO profile — that you're logged in ( aws sso login --profile <name> ) before launching Cowork. The profile's role needs Bedrock invoke permissions on the models you plan to use.
  • Awareness of what's available where. The Chat tab, Computer Use, and Skills Marketplace require Anthropic-hosted inference and aren't available with Bedrock. Cowork and Claude Code are both fully supported against Bedrock.

Install and configuration walkthrough

  1. Download and install the Claude desktop app.
  1. Launch the app but do not sign in. Signing in routes you down the Anthropic-hosted path; you want to configure Bedrock before anything else.
  1. Enable Developer Mode from Help → Troubleshooting.
  1. Open Developer → Configure third-party inference and fill in:
  • Provider: Bedrock
  • AWS region (a region that has the models you want;  us-east-1  is a safe default)
  • Authentication: either a Bedrock bearer token or an AWS CLI profile name. If you pick a profile, confirm it's configured locally and you're logged in (for SSO) before starting.
  • Model list (see the next section — this is the trickiest part)
  1. Enable Skip deployment-mode chooser so Cowork doesn't prompt for cloud vs. 3P every launch.
  1. Allow egress in the sandbox settings. If your environment is not egress-restricted,  *  is the simplest value. If it is, allow-list only what your MCP servers need.
  1. Configure MCP servers (covered in its own section below).

The model list

Model configuration lives in the 3P managed config ( ~/.claude/cowork-3p-config.json ), under the top-level  inferenceModels  key. Cowork's 3P config UI exposes this field as a model list that, on the surface, looks like a simple array of strings — one Bedrock inference profile ID per line. For most models that's all you need:
JSON
"inferenceModels": [
  "global.anthropic.claude-opus-4-7",
  "global.anthropic.claude-sonnet-4-6",
  "global.anthropic.claude-haiku-4-5-20251001-v1:0"
]

The first entry in  inferenceModels  becomes the default model selection in the picker, so order your list with your preferred default at the top.
To get the exact model ID for an entry, go to the Amazon Bedrock console and look up the model. Remember that inference profiles are what you want here, not the raw model identifiers — check the "Inference profiles" section for the global and regional profile IDs.

A note on 1M-context models

Several Claude models support an extended 1M-token context window. Accessing that extended window requires an additional beta header on each request ( anthropic-beta: context-1m-2025-08-07 ). Some tools, including Claude Code, accept a  [1m]  suffix on the model name as a shorthand to flip that header on — for example,  global.anthropic.claude-opus-4-7[1m] . That shorthand may appear to work in Cowork, but it's not the supported mechanism there and isn't guaranteed to inject the beta header correctly.

Configuring a 1M-context model

Note: 1M context cannot be configured through the settings UI — the form only accepts strings, and the object entry Cowork needs is rejected. You'll need to edit the 3P managed config file by hand, and doing so currently disables the settings window. The steps below walk through the full workflow.
Cowork exposes 1M context through a  supports1m: true  capability flag on the model entry — not via a suffix, and not via anything you can type into the settings form. Using Opus 4.7 as the example, the entry you want in  inferenceModels  is:
JSON
{ "name": "global.anthropic.claude-opus-4-7", "supports1m": true }

When Cowork sees this, it adds a separate picker row for the 1M variant (alongside the standard one, which it still surfaces automatically) and injects the  anthropic-beta: context-1m-2025-08-07  header on requests for that variant. In the model picker you'll see something like "Opus 4.7" and "Opus 4.7 (1M)" as two separate choices.
Two things to know before you add this entry:
  •  supports1m: true  is a capability assertion. Cowork takes your word for it and doesn't verify with Bedrock. If you set it on a model whose deployment doesn't actually support 1M, the request will fail mid-session once the conversation crosses ~200K tokens.
  • The model ID must match exactly what Cowork discovers from your provider. If the 1M variant doesn't appear in the picker, the most likely cause is a mismatch between the  name  you set and the ID Cowork is using.

Why you can't add this through the settings form

The 3P config form treats every entry in the model list as a string. If you try to paste  { "name": "...", "supports1m": true }  into that field, the form wraps it in quotes and escapes the braces, producing something like  "{ \"name\": ..., \"supports1m\": true }"  that Cowork can't parse at runtime. The supported approach is to edit the 3P managed config file directly.

Editing the file: step-by-step

Here's the end-to-end workflow to enable 1M context for Opus 4.7:
  1. Quit Cowork fully (Cmd+Q — not just close the window). The app may overwrite your changes on quit if it's still running.
  1. Locate the 3P managed config file. From the 3P config window, use the Reveal in Finder option — it takes you straight to the file. It lives under  ~/Library/Application Support/Claude-3p/configLibrary/  with a UUID filename. Once you've found it, symlinking it somewhere convenient saves a lot of hunting on future edits: __PRE_PLACEHOLDER_3__
  1. Open the file in your editor. For example: __PRE_PLACEHOLDER_4__
  1. Replace the Opus 4.7 string entry in  inferenceModels  with the object form. A full  inferenceModels  array with Opus 4.7 configured for 1M looks like this: __PRE_PLACEHOLDER_5__ Note that you don't need to keep  "global.anthropic.claude-opus-4-7"  as a separate string entry — the  supports1m: true  object entry gives you both the standard and 1M picker rows automatically.
  1. Save the file.
  1. Relaunch Cowork and confirm in the model picker that you see separate "Opus 4.7" and "Opus 4.7 (1M)" entries.

The 1M-entry side effect: a disabled settings window

One thing worth knowing up front: as of this writing, once you have an object entry in  inferenceModels , the 3P config window no longer opens — it goes blank because the form doesn't know how to render object-shaped entries. The underlying runtime parses the config fine, so Cowork itself works normally; only the settings UI is affected.
If you need to get the config dialog back (to rotate a token, change a region, update MCP servers through the UI), temporarily remove the object entry from the file, open the UI, make your changes, then put the object entry back. A simple way to keep both states around:
Bash
cp ~/.claude/cowork-3p-config.json ~/.claude/cowork-3p-config.1m.backup.json

This will almost certainly smooth out as the feature matures; it's a rough edge of a preview release.

MCP server configuration

Cowork supports two distinct ways of wiring up MCP servers, each living in a different config file and with different lifecycle and permission semantics:
  1. User-added MCP servers — local stdio servers you add for yourself, defined in the  mcpServers  block of  ~/Library/Application Support/Claude-3p/claude_desktop_config.json . These are the ones you're most likely to bring over from Claude Code.
  1. Managed MCP servers — remote HTTPS servers declared under the top-level  managedMcpServers  key of the 3P managed config ( ~/.claude/cowork-3p-config.json ). These are admin-provisioned and support per-tool permission locks via  toolPolicy , a capability that is not available for local stdio servers.
The two files coexist. Use the user config for personal local tools, and the managed config whenever you have a remote HTTPS MCP whose permissions you want to set explicitly rather than approve interactively.

User-added MCP servers

For personal tools — particularly the local stdio servers you likely already use with Claude Code — you'll add entries to  mcpServers  in the Claude desktop user config file. The JSON format is nearly identical to Claude Code's  mcpServers  block. Using an Asana MCP server as the example:
JSON
{
  "mcpServers": {
    "asana-local-mcp": {
      "type": "stdio",
      "command": "asana-local-mcp",
      "args": [],
      "env": {
        "PATH": "/Users/you/bin:/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

Step-by-step:
  1. Quit Cowork fully (Cmd+Q).
  1. Open the user config file: __PRE_PLACEHOLDER_8__ If the file doesn't exist, create it with an empty object  {}  and start from there.
  1. Add (or extend) a  mcpServers  block at the top level of the JSON. Add one object per server you want to enable. Set  command  to the binary name or an absolute path (see  MCP runtime considerations  below for why the absolute path is sometimes required).
  1. Save and relaunch Cowork.
  1. Confirm the server registered by checking its tool list in a new Cowork conversation, or by looking at the MCP log.
Tools from user-added servers follow Cowork's default interactive approval flow (you approve each tool call on first use). There is no user-config mechanism to pre-approve or lock permissions on local stdio servers; if you need that, see the managed-server approach below. If you want to skip approvals entirely at the session level, the Bypass Permissions toggle turns off prompting for all MCP tool calls in a session — useful in developer mode but worth understanding before you leave it on.

Managed MCP servers (with toolPolicy)

Managed MCP servers are declared under the top-level  managedMcpServers  key of the 3P managed config file ( ~/.claude/cowork-3p-config.json ). They must be reachable over HTTPS, and they support a  toolPolicy  field that lets you set per-tool defaults ( allow ,  ask , or  blocked ). This is the only way in the current config schema to pin MCP permissions without interactive prompts.
The  AWS Knowledge MCP Server  is a great example: it's a public HTTPS endpoint, requires no authentication, exposes a handful of read-only documentation tools, and is a natural fit for  "allow"  defaults.
Step-by-step:
  1. Quit Cowork fully (Cmd+Q).
  1. Get the exact tool names. MCP tool names often include server-specific prefixes that aren't obvious from the server's documentation. The AWS Knowledge MCP Server tools, for instance, are prefixed with  aws___  — so the tool you'd think of as  search_documentation  appears as  aws___search_documentation  in Cowork. Two reliable ways to discover the actual names:
  • Option A: Register the server as a user-added entry first (in  claude_desktop_config.json , using the fastmcp bridge described in  MCP runtime considerations  for HTTP transport). Relaunch, connect, then open Settings → Connectors, find the server, and copy the tool names from its permission list. Once you have the list, remove the user-added entry and proceed with the managed form.
  • Option B: Look up the server's tool schema from its documentation or  tools/list  MCP response.
  1. Open the 3P managed config file: __PRE_PLACEHOLDER_9__
  1. Add  managedMcpServers  as a top-level native JSON array, sibling to  inferenceModels  and any  mcpServers  block. Example with AWS Knowledge MCP: __PRE_PLACEHOLDER_10__ Notes:
  •  transport: "http"  is the default; included for clarity.
  •  toolPolicy  values:  "allow"  auto-approves,  "ask"  prompts,  "blocked"  rejects.
  • If your MCP requires auth, use  oauth: true  (for PKCE),  headers  (for static tokens), or  headersHelper  (for short-lived tokens fetched via a local executable). See the 3P configuration reference for the full field list.
  1. Save the file.
  1. Relaunch Cowork.
  1. Verify in Settings → Connectors. The server should appear in the connector list with an admin-managed indicator. Opening its permission panel will show each tool locked to the policy you set.
MCP server configured as enterprise server

MCP server permissions assigned automatically

One subtle benefit of this approach for the AWS Knowledge server specifically: it avoids the need for the  uvx fastmcp run <url>  stdio-bridge workaround Cowork has required for HTTP transport elsewhere. Managed servers connect directly over HTTPS.
Note: A config-file format note: the  managedMcpServers  value is a native JSON array when editing the Cowork 3P managed config file directly. You may see the Cowork docs refer to "JSON array as a string" — that form applies only when delivering the configuration via a macOS  .mobileconfig  MDM plist, which requires array values to be string-encoded. Inside the JSON file, the native array form is what Cowork parses.

MCP runtime considerations

A grab bag of things that tend to bite when moving MCP servers to Cowork, particularly the local stdio ones you may be bringing over from Claude Code. Everything below applies to the user-added servers in  claude_desktop_config.json ; managed servers connect over HTTPS and don't hit these issues.

Cowork spawns MCP servers outside your shell

Claude Code launches MCP servers through your login shell, so they inherit your full  PATH , any  mise / asdf / nvm  activation, virtualenv setup, and the rest of your dotfile setup.
Cowork does not. Cowork spawns each MCP server as a direct child process with a minimal, hardcoded  PATH  — the same restriction that applies to any macOS GUI app launched from Finder. In practice that means:
  •  ~/.zshrc  is not sourced.
  •  mise / asdf / pyenv  shims outside the default path list are invisible.
  • Tools installed to non-standard locations are not on the search path.
You'll see this surface as:
Plain text
Failed to spawn process: No such file or directory

…even for a command you can run fine in a terminal.

The fix: absolute paths or explicit  env.PATH 

Two patterns work. Pick whichever feels right for a given server.
Option 1: point  command  at the absolute path to the binary:
JSON
"my-mcp-server": {
  "type": "stdio",
  "command": "/Users/you/bin/my-mcp-server",
  "args": [],
  "env": {}
}

Option 2: keep  command  short but set  env.PATH  so the script can find the binaries it needs. This is the form you want when the MCP server itself shells out to other tools:
JSON
"my-mcp-server": {
  "type": "stdio",
  "command": "my-mcp-server",
  "args": [],
  "env": {
    "PATH": "/Users/you/bin:/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin"
  }
}

A very common failure mode is an MCP server that launches successfully but then dies immediately with  exec: somecommand: not found  in the log. That's always the inner command missing from  PATH . Add the directory containing that tool to  env.PATH  on the server entry.

The log file is your friend

Cowork writes detailed MCP logs. When a server refuses to start, the log tells you:
  • The exact command and  PATH  it used
  • The initialization handshake (or lack thereof)
  • Stderr output from the server process — including shebang errors, missing commands, and auth failures
Find the log path for your install (it's reachable from Developer tools) and keep it open in a second window while you're iterating.

HTTP / SSE remote MCP servers need a stdio proxy when added as user servers

Claude Code supports remote MCP servers configured as  "type": "http"  directly in  mcpServers . Cowork, as of this writing, does not — the  mcpServers  block in  claude_desktop_config.json  only understands  stdio . If you drop an HTTP entry into  mcpServers , Cowork silently ignores it, which is frustrating because the logs never mention it.
Two ways around this:
  • Preferred: move the server to  managedMcpServers  in the 3P managed config. That block natively supports HTTP/SSE transport and gives you  toolPolicy  for free. See the managed servers section above.
  • If you need a user-added workaround (for example, while you're still discovering the tool names before migrating to managed), proxy the HTTP server through a local stdio bridge. The AWS-recommended bridge is   fastmcp  : __PRE_PLACEHOLDER_14__  uvx fastmcp run <url>  turns a remote HTTP endpoint into a local stdio process Cowork can talk to.

Best practices and lessons learned

A grab bag of things worth internalizing:
Know your two config files.  claude_desktop_config.json  holds user-scoped MCP servers; the 3P managed config holds inference settings and admin-scoped MCPs with permission policy. Mismatching the file is the most common configuration mistake.
Until enterprise management is in place, plan on editing the config files directly. In the long-term model, an MDM tool pushes a signed config to each endpoint and users never touch it. During the preview, and without that tooling, you'll be editing the underlying JSON files yourself for anything beyond what the settings UI exposes. Symlink the 3P config somewhere convenient and keep a backup of a known-good state.
Use global inference profiles. Names like  global.anthropic.claude-opus-4-7  handle cross-region routing automatically and spare you from tracking which Claude version is available in which region on a given day.
Know which capabilities are Cowork-only vs. Anthropic-only. The Chat tab, Computer Use, and Skills Marketplace need Anthropic-hosted inference. Cowork and Claude Code both run happily on Bedrock.
Remember this is a preview. The configuration surface, the UI, and even file locations may change between releases. Don't over-invest in workarounds for today's rough edges — most will be smoothed out, and some of the advice in this post will age quickly.

References

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article