A scheduled job has been failing for a week on one remote MCP server. Run by hand from a terminal on the same machine, with the same configuration, everything works. The job's logs show the server's tools were unavailable, and a colleague proposes adding a retry loop around the whole run. What is actually wrong, and what fixes it?

The principle — When something works by hand and fails on a schedule, the difference to look for is what the two kinds of session can do, not what the environment was like at the time.

Why the key is correct — In non-interactive mode there is no MCP panel, so Claude Code cannot run the sign-in flow for the job. Claude Code marks a remote server as needing authentication when the server responds with 401 Unauthorized or 403 Forbidden, and in a scripted run that state simply persists: the tools stay unavailable and nothing can ask anyone to fix it. Signing in once from an interactive session on that machine stores a credential, and because authentication tokens are stored securely and refreshed automatically, the scheduled run then has something to use. That is the fix, and it is a one-time action rather than a change to the job.

Why the others are wrong — Schedule and network differences would produce intermittent failures rather than a week of identical ones. Credentials are not walled off from other sessions; the whole design assumes they are reused. And a retry loop repeats an operation whose outcome is fixed, so it converts one deterministic failure into several.

Remember this — Works by hand, fails on a schedule: ask what the scheduled session is unable to do, rather than what was different about the moment it ran. The list of things a non-interactive session cannot do is short, and signing in is on it.

Sources — Anthropic's Claude Code MCP reference.