# Host CLI Access for Claude Cowork *March 2026* [Claude Cowork](https://docs.anthropic.com/en/docs/claude-cowork) runs tasks in a sandboxed VM. It can't call binaries on your machine. This is fine until you need it to check your email, search your notes, or interact with some authenticated CLI tool. For example, I want to use Cowork to manage multiple email inboxes. At the time of writing, the native Gmail connector in Claude Desktop only supports one account and can't archive emails, which is more than half of what I do with email. I already have a CLI for this ([`gog`](https://github.com/steipete/gogcli)), and I'd been using it through Claude Code and Codex with full shell permissions. That worked when I was sitting there. It's less fine for a scheduled Cowork task running before I wake up. There are some tricks, like running the session in a folder where the binary exists, but that relies on the assumption that the binary location is also where the configuration and secrets live. I'm also not a fan of patching tools that already work because of harness constraints. So I built [`bash-mcp-bridge`](https://github.com/ryanlyn/bash-mcp-bridge). It's an MCP server that runs on the host and exposes an `execute` tool that gives the sandbox a narrow bridge into the host. It has two constraints: 1. **Binary whitelist.** You declare which binaries the agent can use. Everything else gets rejected. 2. **No shell.** Commands are exec'd directly, not passed to `/bin/sh`. No interpretation, no globbing, no expansion. Standalone shell operators like `|`, `&&`, and `>` are rejected at the token level. The agent sends a command string, the server tokenizes it, checks the binary name against the whitelist, and runs it. stdout, stderr, and exit code come back as structured data. Now a Cowork task can call `gog gmail archive --query "older_than:3d label:promotions"` through the bridge, and it can only do what the explicitly whitelisted binary itself allows. It can't `rm` anything, can't redirect output, can't chain commands. Setup is just: ```json { "mcpServers": { "bash-bridge": { "command": "bash-mcp-bridge", "env": { "XDG_CONFIG_HOME": "<env vars are not inherited>" }, "args": [ "--allow", "gog", "--allow", "gh" ] } } } ``` In `~/Library/Application Support/Claude/claude_desktop_config.json`. That gets me closer to the thing I actually wanted: managed host-side automation with a narrower blast radius.