Claude Remote Control: Why My Phone Could Not Start a Session
Research Log [2026 08 16]: Diagnosing and Automating a Phone-to-PC Remote Control Link for an LLM Agent
1. Objective
Driving an LLM agent on a desktop machine from a phone is useful for a specific reason. The agent operates on the real files that exist only on that machine, including models, scripts, and drawings, so work started at the desk can be continued while away from it. A cloud session cannot do this, because the files are not there.
The link had been in use for about a month and it stopped working one morning. This log documents the diagnosis, the three separate causes that were found underneath the failure, and the configuration that now survives a reboot. It also documents six errors in my own diagnostic reasoning, because those errors consumed roughly five hours and are more generally useful than the fix itself.
2. Summary of Work
The failure had three independent causes that happened to coincide. A refresh token had expired on a thirty-day clock, an autostart registration that a previous session had recorded as complete did not exist on disk, and the command being used to host the connection was the wrong one. The third cause was mine, and I asserted three separate times that the correct solution was structurally impossible before the product documentation was consulted and proved otherwise.
A launcher script, a login script, and a scheduled task were then written and verified. One further trap appeared during that work, involving line endings and character encoding in a Windows batch file, which had already been documented in my own records and was reproduced anyway.
3. Symptom
The failure arrived with an unusually clean set of constraints. The link had worked on both of the preceding days, the machine had not been rebooted at any point, and the launcher nevertheless produced the following on startup.
Error: You must be logged in to use Remote Control. Remote Control is only available with claude.ai subscriptions. Please use `/login` to sign in with your claude.ai account.
The first diagnostic error is already visible here. When asked why the remote link was down, I did not read that screen. I inventoried the startup folder, the task scheduler, and two registry run keys instead, and then reported that nothing was registered for autostart. The report was accurate and it was not the cause of the failure that was actually in front of us.
4. Cause 1: a refresh token expires on a thirty-day clock
The credentials file was present and the subscription was active, but the token bodies themselves had been emptied.
accessToken = <length 0> empty refreshToken = <length 0> empty expiresAt = 0 subscriptionType = max subscription active scopes = user:inference user:profile ...
4.1 Why the desktop application continued to work
There are two authentication paths in this product and they do not share state, so one of them can fail while the other continues normally.
| Path | Source of the token | State that morning |
| Desktop application | The application process holds the token and injects it into child sessions | Working |
| Standalone CLI, used by the remote launcher | Reads the credentials file from disk | Failing |
This produces a confusing class of symptom, because the application works and the account is therefore assumed to be healthy, which makes the remote feature look like the broken component. The account was in fact the broken component, but only for one of its two consumers.
4.2 Measurements taken after logging in again
| Field | Before login | After login |
| accessToken length | 0 | 108 |
| refreshToken length | 0 | 108 |
| expiresAt | 0 | same day, plus 8 hours |
| refreshToken expiry | not available | plus 28.9 days |
A refresh token with a lifetime of 28.9 days accounts for the entire failure, and the back-calculation lands on the exact morning in question.
refresh token lifetime = 28.9 days CLI install date = 2026-07-17 (executable creation time) project log entry = "2026-07-17 | phone remote-control connected" 2026-07-17 + ~30 days = 2026-08-16 the morning of the failure
This also answers the objection that the computer was never switched off, since expiry runs on wall-clock time and has no relationship to power state. A login performed once will come apart roughly a month later without anything having happened in between.
4.3 A theory that the timestamps refuted
My first hypothesis was that a recent update to the CLI had changed the way credentials are stored, which is a reasonable thing to suspect and was straightforward to test.
failure 07:57:48 CLI auto-update 08:31:07 (34 minutes later)
The update landed after the failure and therefore could not have caused it. The general form of this check is worth stating plainly: a recent change is not a cause until the time it changed has been compared against the time the system broke, and both numbers are usually one command away.
5. Cause 2: an autostart that existed only as a log line
My own project log contained the following entry from three weeks earlier.
- 2026-07-25 | Remote Control disconnect-after-reboot diagnosis; autostart configured | #infra #autostart | (in progress) output link TBD
The entry states that autostart was configured, while the output link records that nothing was produced. A sweep of the four locations in which a Windows autostart entry can live found no registration of any kind.
| Location | Result |
| Startup folder | 2 unrelated entries |
| Task Scheduler | 0 matches |
| Registry HKCU\Run | none |
| Registry HKLM\Run | none |
The launcher script implied by that log entry did not exist on disk either, so for three weeks the process had been started by hand and had disappeared at every reboot while the written record described it as automated. The completion condition for automation work should therefore be stated as an observation rather than an action: the registration exists on disk, and the behaviour was confirmed after an actual reboot. A log line that still reads "in progress" with no output link describes an abandoned task rather than a finished one.
6. Cause 3: the flag is not the subcommand
6.1 What I asserted three times
After the re-login and a working autostart, attaching the phone to a session that was already open on the desktop worked correctly. Creating a new conversation from the phone hung on "Connecting" indefinitely, and I reported the following.
The --remote-control option shares a single session that is already running on the PC. A standing host mode, in which the phone requests a session and the PC creates one, does not exist in the CLI. I have reviewed the entire help output and there is no daemon, serve, or listen option.
I then recommended, in writing, that new conversations should not be created from the phone and that the session already open on the desktop should be used instead. The objection raised against that recommendation was that it described a surrender rather than an answer, and that a paid subscription should not require abandoning a feature the product advertises. Both parts of the objection were correct.
6.2 The answer was printed in the mobile application
A screenshot of the application arrived shortly afterwards, showing the onboarding sheet for connecting a computer. Translated from the original, it reads as follows.
Connect a computer
In your computer's terminal, open the project you want Claude to work in,
then run this command:
claude remote-control
or
claude rc
Once it is running, come back here and pick your computer from the list.
The product had documented the correct command inside the application, on the screen the user was already looking at, and I had neither requested that screen nor consulted it. My reasoning had produced a conclusion of impossibility while the answer was sitting one screenshot away.
6.3 Two hyphens
Only at this point did I run the help output for the subcommand rather than for the top-level command.
$ claude remote-control --help Remote Control - Control local sessions from claude.ai/code or the Claude mobile app OPTIONS --name <name> Name for the session (shown in claude.ai/code) -c, --continue Reattach ... instead of creating a new one --session-id <id> Reattach ... (cannot be used with spawn flags ...) --permission-mode <mode> Permission mode for spawned sessions
The phrases spawned sessions and spawn flags describe exactly the capability I had spent several hours declaring absent, and they appear in the help text of the command that provides it.
| Command | What it is | New conversation from the phone |
claude --remote-control [name] | A flag, which shares the single session already running | Not possible |
claude remote-control, abbreviated claude rc | A subcommand, which runs a host that accepts requests and creates sessions | Works |
The two commands are separated by two hyphens and are entirely different objects. The top-level claude --help lists the flag and says nothing about the behaviour of the subcommand, so a reader who consults only the top level will find no daemon and may generalise incorrectly from that absence.
6.4 Output after the correction
Connected . <machine> . HEAD
Capacity: 0/32 . New sessions will be created in the current directory
Continue coding in the Claude mobile app or https://claude.ai/code?environment=<env-id>
space to show QR code . w to toggle spawn mode
The line Capacity: 0/32 reports that the machine will create up to thirty-two sessions on request, and the following line explains why the launcher has to change into the working directory before starting, since sessions are otherwise created in whatever directory the scheduler happened to use. The phone created a new conversation successfully on the first attempt.
7. A batch file that failed silently
With the command corrected, the launcher continued to die whenever the scheduler started it, while running correctly when started by hand. Capturing the full output of the batch file explained the difference.
'--remote-control`.' is not recognized as an internal or external command... '"spawn flags"' is not recognized as an internal or external command... 'E_EXE' is not recognized as an internal or external command... Folder : variable is empty [FATAL] claude.exe not found: also empty
The REM comments were not being treated as comments at all; they were being executed as commands. The file had been written with LF line endings and with non-ASCII characters inside the comment text, and the Windows command interpreter does not parse such a file reliably. It also does not fail cleanly, which is the property that makes the problem expensive to find.
This particular trap was already recorded in my own notes from an earlier project, in which a batch file failed instantly for the same reason. I did not search those notes before writing the file and therefore reproduced the fault. The first launcher written that morning had survived only by accident, because it happened to contain no non-ASCII characters, and it broke at the moment Korean comments were added during the rewrite for host mode.
The correction is to write the file as pure ASCII with CRLF endings, and then to verify it in bytes rather than by reading it.
bytes = 1676 non-ASCII bytes = 0 CRLF count = 51 LF-only count = 0
The generalisation is worth recording, because an LLM agent writing files will default to UTF-8 with LF endings, and that default is correct almost everywhere except here. When an agent is asked to produce a Windows batch or command file, ASCII and CRLF should be stated as explicit requirements and the resulting bytes should be checked, since an intermittently working script costs considerably more time than one that fails outright.
8. Final configuration
| Component | Detail |
| Launcher batch file | claude remote-control, the host subcommand, changing into the working directory first, written as ASCII with CRLF |
| Login batch file | A dedicated window for /login, for occasions when opening a terminal is inconvenient |
| Scheduled task | At logon plus one minute, with no execution time limit, restarting on failure three times at two-minute intervals, using an interactive token |
| Desktop shortcuts | Two, for manual start and for logging in again |
8.1 Reasons for those particular settings
- One minute of delay after logon. The network is frequently not available immediately after boot and the launcher fails when it is not.
- No execution time limit. The scheduler applies a default limit of three days and then terminates the task without reporting anything.
- An interactive token. The window must be visible in order to read its state or to stop it by hand.
- A policy for duplicate instances. Restart-on-failure combined with a manual start produces two hosts, after which the device list on the phone becomes ambiguous. This occurred during the session.
- Changing into the working directory. The host creates sessions in the current directory, so the current directory is a functional setting rather than housekeeping.
8.2 Verification
| Claim | Method | Result |
| Autostart, flag version | An actual reboot | The window started without intervention |
| Phone to desktop round trip | A screenshot sent from the phone, with transcript size tracked on the desktop | 11 KB, then 186 KB, then busy, then 384 KB, then idle |
| Bridge stability | Logged once a minute for fifteen minutes | No disconnections |
| Host mode started by the scheduler | Started through the scheduled task and observed | Survived for the 66 seconds observed |
| New conversation from the phone | Ordinary use | Works |
9. Six errors in the diagnosis
| # | What was done | Why it was wrong | The rule it violates |
| 1 | Searched the registry rather than reading the error on screen | The error message named the cause | A failure screen is first-class evidence, and it should be requested before any theory is offered |
| 2 | Interpreted the phrase "it will not connect" without checking it | The intention was to create a session, not to attach to one | Establish what the user was attempting before diagnosing what failed |
| 3 | Read the top-level help and concluded the feature was absent | The feature was documented in the help for the subcommand | Help output covers one level, so the help for each relevant subcommand must be read separately |
| 4 | Never consulted the instructions inside the product | The application displayed the exact command required | Onboarding text is a primary source and it outranks inference |
| 5 | Read a falling count of TCP connections as a fault | The count rises and falls with each request and the normal range is wide | Observe the normal range of a metric before setting any threshold on it |
| 6 | Wrote the batch file with LF endings and non-ASCII characters | The same trap was already recorded in my own notes | Search existing records for known traps before beginning |
9.1 The error underneath the other six
A statement that a feature does not exist is a claim of absence, and a claim of absence is only supported by exhaustive checking. I made that claim three times on partial evidence, and each occasion sent the work further down a worse path, ending in a recommendation to stop using the feature altogether. The fifth error has the same shape, since a metric was treated as a fault signal before anyone had observed what it looks like under healthy conditions, and two working sessions were terminated as a result.
The practical consequence for anyone working with an agent is a question worth asking whenever impossibility is asserted. The useful question is not whether the agent checked, but what it checked. An answer of "I read the help" is not sufficient, whereas an answer naming which help output was read, and whether it was read in full, can be evaluated.
10. Checklist for a failing link
- Read the error on the desktop screen exactly as written, and provide it as a screenshot rather than asking anyone, human or otherwise, to guess at it.
- If the error refers to login, log in once. Tokens expire on a roughly monthly cycle, which is a schedule rather than a fault, and it will recur predictably.
- State the intended action rather than the failure. Attaching to a session already running on the desktop and starting a new conversation from the phone are different requests that require different commands.
- Open the instructions for connecting a computer inside the application. The command printed there is the correct one.
- Run that command on the desktop first, and only then select the machine on the phone. Performed in the other order, the connection hangs indefinitely.
- If the startup was automated, reboot the machine and watch it. A registration is not an observation.
10.1 How to phrase the request to an agent
A request of the form "remote is not working, please fix it" invites exactly the failure described above. A more productive form states the evidence and the intention together, along with an explicit instruction about method: the remote link is not working, this is what the screen displays, the intention is to create a new conversation from the phone, and the error text and the official instructions should be checked before any answer is given. The clause that saves the time is the instruction to check sources before inferring, and in this session it would have been worth approximately five hours.
11. What I could not verify
- Host mode across a real reboot. The flag version was confirmed by rebooting the machine. The host-mode launcher was confirmed by starting it through the scheduled task and observing that it survived, but the machine has not been rebooted since, so that check remains outstanding.
- Whether the token expired or the refresh request was rejected. The evidence establishes that the fields were empty and that a 28.9-day lifetime lands on the date of the failure. It cannot separate an expired refresh token from a refresh request that was rejected at that moment, because logging in overwrote the field that would have settled the question.
- One unexplained server-side error. A worker registration for a session identifier returned HTTP 404 on a single occasion about two hours after recovery, with no observable effect. A stale session from earlier in the morning is the most plausible explanation, and it is recorded here as a hypothesis rather than a finding.
댓글
댓글 쓰기