Short answer: Most CLI agents store your MCP config and OAuth tokens in local files (~/.claude, ~/.cursor, ~/.config/opencode), so an agent running in the cloud doesn't see them. You have three ways around that. You can register the server as a Claude connector, which syncs from claude.ai down to Claude Code but not back up. You can self-host your agent on a VPS and configure MCP there by hand. Or you can use fl0w, which keeps your MCP servers and tokens in sync between your laptop and a personal cloud computer in both directions.
What MCP actually is (and why it's tied to your laptop)
MCP sounds like a new concept, but anyone who has built SaaS integrations has known the underlying pieces for a long time.
Most people use MCP, at least for exposing tools, as a wrapper on top of an API. Slack has a post message API that takes the text you want to post, a channel ID, and a few other parameters. MCP wraps each parameter with an LLM-readable description and exposes the whole thing as something an LLM can call.
When MCP added OAuth to the protocol, it removed the need to hardcode credentials. Instead, you sign in on an OAuth page, and it returns two tokens:
- an access token, which is a temporary, short-lived token (kind of like a password) that says you are who you say you are, and
- a refresh token, which gives you a new access token when the old one expires.
OAuth and APIs have been around forever. Now they're accessible to LLMs. MCP also includes things like elicitation and resources, but I think most people use it as a convenient way to expose tools, plus OAuth.
Here's the catch. Claude Code, the Cursor CLI, and most other CLI tools run locally, so they store your access and refresh tokens in a JSON file, a YAML file, or some other config file on your machine. That's why your home directory now has a .claude folder and a .cursor folder, each with config files that track your MCP setup. And it's why, for agents with both a local side and a remote side, the tokens don't always sync.
This matters once you want an agent working while you're away: a scheduled task, a background job, or a session you start from your phone.
Option 1: Claude connectors
If you use Claude, connectors are the built-in way to give your cloud sessions MCP tools. You add a server at claude.ai/customize/connectors and sign in once. It's then available on claude.ai on the web and on mobile, in Claude's cloud scheduled tasks, and in Claude Code on your laptop.
I use Claude Code on an Enterprise plan through my company, and the plugins and MCP connectors that my org configures, or that I add on the website, sync automatically when I open Claude Code. At my computer, I'm happy using Claude Code. The advantage of claude.ai is that I can use it anywhere from my phone, which is especially handy for background jobs and scheduled tasks. Because the connectors carry over, I don't have to add the MCP server or plugin again. When it's seamless, it's great.
Limitations
It's not always one-to-one, though.
- It syncs one way: remote to local. Servers you add on claude.ai flow down to Claude Code. But when I configure an MCP server locally in Claude Code, its tokens and auth don't show up on claude.ai. Claude's docs confirm that servers added with
claude mcp adddon't appear in the connector list for cloud scheduled tasks. To use one remotely, you add it again as a connector, or commit it in a repo's.mcp.json. - Local and remote auth are separate. A lot of the time I end up authenticating the same service twice: once in Claude Code, once on claude.ai.
- Remote servers only. A connector has to be reachable from Anthropic's servers. A stdio server you run with
npxon your laptop, or something behind your VPN, can't be a connector.
Option 2: OpenCode (or any agent) self-hosted on a VPS
The other route is running your agent on a server you control. OpenCode, for example, can run headless on a VPS (opencode serve), and you configure MCP servers in its config file on that box the same way you would locally.
This isn't only a Claude problem. I also use the Cursor CLI for personal projects, and the custom skills and MCPs I've configured locally don't always carry over when I use Cursor's background agents. Running your own box at least gives you full control. Stdio servers work, private network access works, and nothing gets filtered through someone else's connector list.
Limitations
- No syncing between your local agent and your VPS. Your laptop and your server are two separate installs. Add an MCP server locally and you add it again remotely. Change a skill and you copy it over.
- OAuth on a headless box is awkward. The browser sign-in flow expects a localhost callback, so you end up port forwarding or copying token files around. And when a token gets refreshed on one machine, the other machine's copy can go stale and you have to reconnect. See keeping OAuth tokens working for an unattended agent.
- You're running a server. SSH, updates, secrets, and logs are all on you.
Option 3: fl0w, synced both ways
When I built fl0w, this is what I wanted most: local and remote always in sync. As soon as you sign up, you get a personal cloud computer, and your ~/.fl0w config syncs between it and your machine:
+--------------+ +--------------+
| Local | | Remote |
|--------------| fl0w sync |--------------|
| ~/.fl0w/ | -----------> | ~/.fl0w/ |
| +- auth.json| | +- auth.json|
| +- mcp.json | | +- mcp.json |
| +- skills/ | <----------- | +- skills/ |
+--------------+ +--------------+- It syncs both ways. Your MCP tokens are encrypted and sent over HTTPS from your local computer to your remote computer, and changes you make on the remote computer sync back to your local one.
- Tokens stay fresh, so you rarely re-authenticate. A daily job on your remote computer reconnects your MCPs and fetches new tokens, and the refreshed tokens sync back. A token rotated during a 3am scheduled run doesn't leave your laptop with a stale one.
- It's a long-lived sandbox that's yours. It has a terminal and a file explorer, and your files stay there between runs. Clone repos into it, install tools, and keep working directories around without managing a server.
- The same tools work in workflows. MCP servers saved on a workflow are available in unattended runs on a schedule, webhook, or form.
Adding a server takes one command. OAuth runs the first time it connects:
fl0w mcp add linear https://mcp.linear.app/mcp
fl0w reauth linear # sign in now instead of on next startStdio servers work too:
fl0w mcp add fs npx -- -y @modelcontextprotocol/server-filesystem ~/codeWhenever you start fl0w, locally or remotely, your configs, MCPs, tokens, and skills are in sync. That's how you run MCP servers remotely the same way you run them locally. See Adding MCP connectors and How it works for details.
Comparison
| Claude connectors | Self-hosted agent on a VPS | fl0w | |
|---|---|---|---|
| Local → cloud sync | No | No (manual copy) | Yes |
| Cloud → local sync | Yes | No | Yes |
| Stdio / local MCP servers in the cloud | No | Yes | Yes |
| Token refresh shared across machines | Separate auth per side | Manual | Synced |
| Persistent files and terminal | No (fresh session per run) | Yes | Yes, with file explorer UI |
| Ops work | None | High | None |
FAQ
How do I use my Claude Code MCP servers in the cloud?
Servers added with claude mcp add are stored locally and don't carry over to Claude's cloud sessions or scheduled tasks. Add the server again as a connector at claude.ai/customize/connectors, or commit it in a repository's .mcp.json so cloud runs that clone the repo pick it up.
Do Claude connectors sync to Claude Code?
Yes. Connectors you add on claude.ai are available in Claude Code. The reverse isn't true: local MCP servers don't sync up to claude.ai.
Where does Claude Code store MCP OAuth tokens?
On your machine, alongside its other local config, separate from your claude.ai account. That's why you can end up signing in to the same service once locally and again on the web.
Can I run a stdio MCP server in a remote environment?
Only if the remote environment can run the command itself: a VPS you control, or a personal cloud computer like fl0w. Hosted connector systems need a remote HTTP server.
Why do I keep having to re-authenticate MCP servers on my server?
It's not random. Access tokens expire (after a week, a day, or even an hour, depending on the provider), and refresh tokens can be rotated. If two machines hold separate copies, a refresh on one can invalidate the other. Keeping one synced copy of the tokens, and refreshing it before it expires, avoids this.