Support unattended authentication for Remote Control on long-running Claude Code instances

Feature request

I run several long-running Claude Code instances as always-on agents, usually on servers/containers where there is no interactive user sitting at the machine.

Remote Control is particularly useful for this kind of setup, but currently an RC-capable Claude Code login requires human reauthentication roughly every 30 days.

I spent some time testing the OAuth behavior to make sure this wasn't something that could already be solved externally with refresh tokens. From what I can tell, it can't.

Current behavior

On Claude Code 2.1.260 I tested the OAuth token flow directly.

A normal Claude Code login with:

• user:profile
• user:inference
• user:sessions:claude_code

works with Remote Control.

However, user:sessions:claude_code appears to have a server-side maximum lifetime of 30 days. Refreshing the credential does not extend that lifetime. The refresh token rotates, but the returned lifetime continues counting down towards the expiry of the original login. Claude Code already refreshes these credentials automatically, so implementing an external refresh-token script doesn't solve this.

I also tested longer-lived credentials:

• user:profile and user:inference can be issued with much longer lifetimes
• user:sessions:claude_code is capped at 30 days
• a long-lived credential without user:sessions:claude_code gets through the Claude Code client-side checks, but Remote Control registration fails with a 403 because the required scope is missing
• setup-token remains a good solution for unattended inference, but cannot be used with Remote Control

So as far as I can tell, there is currently no supported way to run Remote Control indefinitely on an unattended Claude Code instance.

Use case

The use case here is long-running Claude Code agents. For example, I run Claude Code instances that stay alive for weeks or months, perform scheduled/asynchronous work, receive tasks through Channels, and can be managed remotely. These aren't ephemeral CI jobs, they are persistent Claude Code environments.

Requiring a human to authenticate every ~30 days introduces an unnecessary lifecycle dependency for something that is otherwise designed to remain running unattended. This becomes more relevant as Claude Code moves further towards long-running and asynchronous agent workflows.

Proposed solution

I don't think this necessarily means making the existing setup-token more privileged by default. A few possible approaches could work:

• allow an explicit opt-in for Remote Control when creating a setup token
• introduce a revocable machine/agent credential with user:sessions:claude_code
• provide a supported unattended/device authorization flow that can maintain Remote Control access without periodic interactive login

The important part for this use case is having some supported authentication path for Remote Control that doesn't require a human to sign in again every 30 days. The existing 30-day behavior could remain the default for normal interactive Claude Code logins.

Related issues

There have already been requests around using setup-token with Remote Control, including #33105 and #50977.

I think this request is slightly broader. I'm not specifically asking for the existing setup token to bypass the current restriction. I'm asking whether Claude Code can provide a supported authentication model for Remote Control on persistent/unattended instances.

This also avoids trying to work around the restriction by automating the claude.ai browser login, which would be brittle and doesn't seem like the right solution.

Additional context

Products such as Claude Tag also point towards increasingly asynchronous and long-running agent workflows.

I understand that Anthropic-hosted agents have a very different security and execution model from a local Claude Code process, so I'm not suggesting they should share the same authentication mechanism. I mention it only because long-running agent workflows seem to be becoming a more important part of the Claude ecosystem, and having a supported authentication story for persistent self-hosted Claude Code instances would complement that direction.