Feature request: opt-in local bridge so scheduled cloud agents (routines) can use local MCP servers

Problem

There is currently no good way to run a scheduled agent that needs access to local resources (local MCP servers, local sessions/credentials, local files). The three existing options each solve two thirds of the problem:

| Option | Reliable scheduling | Local access | Visible/reviewable runs |
|---|---|---|---|
| Cloud routines (claude.ai/code/routines) | ✅ always runs | ❌ none | ✅ |
| Claude Desktop scheduled tasks | ⚠️ requires app running on an awake machine | ✅ | ✅ |
| launchd/cron + claude -p headless | ⚠️ requires awake machine | ✅ | ❌ no conversation history to open |

Concrete use case

I built a local MCP server (grocery-store connector) that automates my weekly grocery order. It authenticates with session cookies stored on my Mac and re-authenticates via the macOS Keychain — none of which can (or should) leave the machine. I want a scheduled agent to run it every Sunday evening.

• A cloud routine would be ideal for reliability and visibility, but it cannot reach the local MCP server, the session, or the Keychain.
• A Desktop scheduled task works (my current setup) but silently depends on the app running on an awake machine.
• A launchd job running claude -p works too, but the runs are invisible — no conversation to open, inspect, or continue.

Proposal: an opt-in local bridge for cloud agents ("agent runner")

A lightweight daemon on the user's machine that:

1. Registers with the user's Anthropic account as a named runner/device
2. Exposes an explicitly allow-listed set of local MCP servers to that user's own cloud routines (per-server consent, similar to today's tool permission prompts)
3. Lets a routine declare "requires runner: my-mac" — the cloud session then proxies MCP calls through the bridge; if the runner is offline, the run fails visibly (or queues) instead of silently lacking tools

This would combine the reliability and visibility of cloud routines with the local access of Desktop/CLI, without shipping local credentials to the cloud.

Workaround today

Self-hosting the local MCP server over HTTP behind a tunnel (Tailscale/Cloudflare) and registering it as a remote connector works, but pushes non-trivial security burden (auth, exposure of side-effectful tools) onto each user for what feels like a platform-level concern.