CRUD Flow
⌕
artificial intelligence

The Problem with Claude Desktop Scheduled Tasks

Claude Code gives cloud sessions and routines named environments you can see, configure and trust with secrets. Cowork scheduled tasks run in the cloud with none of that, leaving local MCP servers as the only way to keep a single API token out of a prompt.

Ndamulelo Nemakhavhani

· 6 min read

Over the first weekend of November our prepaid electricity ran out. Nobody in the house got a warning.

That should not have happened. I had automation watching the meter. Codex captured the readings every morning, Claude kept a log and projected the balance, and our household already has a Telegram channel where levy reminders land every month. All the pieces were there. The one missing piece was boring: a safe way for a scheduled task to hold a bot token.

Looking for a place to put that token exposed a split inside Claude Desktop that I still cannot make sense of.

One App, Two Cloud Schedulers#

Claude Code cloud sessions, along with the cloud scheduled tasks (formerly Routines) under the Code tab, run in named environments that you choose. You can see which environment a task uses, give it environment variables and a setup script, and store network secrets that an egress proxy attaches to requests after they leave the VM so the agent never sees them. That is a deterministic place to run work, with configuration you control.

Cowork’s scheduled tasks live in the same Desktop app and run in Anthropic’s cloud too, yet none of that environment model carries over. There is no environment to pick, nothing to inspect, and nowhere to store a secret. I do not understand how the Cowork side ended up drifting away from a pattern Anthropic had already built and documented for Claude Code. It looks like the same platform solving the same problem twice, and only one team finished.

A cloud task runner without a secrets boundary forces you to choose between leaking credentials into prompts or turning your laptop back into a server.

Do We Really Need MCP for Every Little Task?#

Sending a Telegram message is a single HTTP call. You POST some text to api.telegram.org/bot<token>/sendMessage. Claude knows how to make that call without any help.

My existing tasks did exactly that. The levy reminder and a weekly parenting brief both had the bot token written straight into their instructions, next to a curl command. It worked, and it was wrong. Anyone who could see the task or its session transcript could see the token. So I revoked it and generated a new one.

The new question was simple: where do I put the token so my scheduled tasks can use it without it sitting in plain text?

Missing Controls, Even Where Environments Exist#

I went looking for a secrets setting for Cowork scheduled tasks. There is none.

The closest thing in the documentation is the Claude Code cloud environments page, and that is how I found the gap above. Even if I moved my household tasks out of Cowork and into Claude Code’s scheduler, Telegram would still fall through the cracks:

  • Network secrets only inject headers or basic auth. Anthropic’s agent proxy can attach a bearer token header or a username and password to a matching host, after the request leaves the VM. Telegram puts the bot token in the URL path (/bot<token>/sendMessage), so the proxy cannot inject it.
  • Environment variables are readable by the session. The docs are explicit about this: environment variables live inside the VM in .env format, visible to any command the session runs and to anyone who shares the environment. Plus, the default Trusted network policy blocks api.telegram.org with HTTP 403 x-deny-reason: host_not_allowed until you build a custom environment with an explicit domain allowlist.

Back on the Cowork scheduled tasks screen in Claude Desktop, you do not even get those trade-offs. The UI does not tell you which environment a task runs in. You cannot pick one and you cannot see one. If a setting exists and you can neither choose it nor see it, then as far as I am concerned it may as well be random.

When I tried to find the local MCP settings instead, they were not where they used to be either. Developer Mode had been tucked under Help -> Troubleshooting, and the shortcut I have used for months to open the local config file was gone from its old spot. I ended up opening claude_desktop_config.json from the terminal like it was 2015.

Okay Then, I Will Build a New MCP Server#

Here is what it took to make one HTTP call safely:

  1. Write a small MCP server, 87 lines of Python, whose only job is to read the token from a file on my Mac and call Telegram.
  2. Put the token in ~/.secrets/telegram.env with chmod 600.
  3. Hand-edit claude_desktop_config.json to register the server.
  4. Restart Claude Desktop, then restart it again.
  5. Switch every task that sends a message to run locally on my machine, because a stdio MCP server only exists while my Mac is on.

It works. Today the energy alerts, the levy reminder and the parenting brief all post through it. But look at that list again. Five steps and a custom server to replace a curl command, because the product has nowhere to put one secret.

“Then Just Run It on Your Mac”#

That is the obvious reply, and it is what I did. It is also a step backward.

The reason to have scheduled tasks in the cloud is that they run when I am away and while my laptop is closed. The moment my alerts depend on a local file and a local MCP, my Mac becomes part of the infrastructure. It has to stay awake, Claude Desktop has to stay open, and a power cut or a restart quietly stops every task that matters. Claude Code already has a cloud environment model for this. Why can Cowork not share it?

Public HTTP Connectors Are the Wrong Default for Personal Automation#

The other reply from the platform is “make it a connector”. Host the MCP server on the internet, put OAuth in front of it, sign in once, and cloud tasks can call it.

For personal automation, that is the wrong default. The things worth automating in my life are domestic: the meter in my flat, my household channel, files on my own machine. I do not want those routed through yet another public endpoint so that a scheduled task can reach them. The private alternative, proper networking with a VPN and identity in front of everything, costs the kind of money and time that enterprises have and households do not.

Closing Thoughts#

Dear Anthropic, please:

  1. Give Cowork the Claude Code environment model. Every scheduled task in Claude Desktop should run in a named environment I choose, can see and can configure, with variables, a setup script and network secrets, so cloud tasks work without my Mac.
  2. Secrets that fit real APIs. Let a task use a named secret anywhere in an outbound request, including the URL path, without the value ever appearing in the prompt or the transcript. On Desktop, back local secrets with the macOS Keychain.
  3. Keep developer config reachable and stop reshuffling settings. Developers set up local MCP servers. Let us open claude_desktop_config.json directly from settings without hunting through troubleshooting menus after every update.
  4. Design for local. Local tools, local secrets and local data deserve the same care as hosted connectors, because for personal automation they are where the work happens.

I like Claude Desktop very much. I use it every day, and it does real work for me and my household. That is exactly why this hurts: the hard parts already work, and it is the plumbing that keeps failing. A household should not need to build an MCP server to be told the lights are about to go out.