Claude Code Remote Control exit code 1: Why systemd Shows status=1/FAILURE and How to Troubleshoot It

After turning Claude Code Remote Control into a systemd service, systemctl --user status showed code=exited, status=1/FAILURE, and the service exited shortly after starting. I ran into this Claude Code Remote Control exit code 1 during a deployment in October 2026: under the same Linux user, one Remote Control connected normally and another would not come up.

The short version: exit code 1 only means claude remote-control itself exited with a failure. It does not tell you why. Stop that service, read the journal, then run it by hand as the same user in the same working directory to get the exact error text. Among the cases the official documentation says exit with code 1, the one most relevant to systemd is a working directory that has not been trusted yet: with no terminal to answer the trust question, the command simply exits.

This post is my deployment notes from an Ubuntu 24.04 (ARM64) server on Oracle Cloud in October 2026, plus a summary of the official Claude Code and systemd documentation (checked on 12 October 2026). Error messages and behavior change between Claude Code versions; the official Remote Control documentation is what counts. User and service names have been replaced with examples like project-a.

What Claude Code Remote Control exit code 1 means

The systemd.exec documentation lists 1 as a generic failure (EXIT_FAILURE) with no specific cause. Only codes of 200 and above mean systemd itself hit an error while starting the process. Different numbers point to problems in different places:

So with status=1/FAILURE, the path and working directory in the unit file are usually already right; the problem comes after Claude Code starts.

What I ran into

My service started with claude remote-control --name ... --spawn=worktree. systemd showed Loaded: ... enabled, but Active: inactive (dead) (Result: exit-code), preceded by code=exited, status=1/FAILURE. At the same time, another Remote Control under the same Linux user was active (running), and I had confirmed Linger=yes.

The logs I have are not enough to confirm the root cause this time, so this post does not claim “I found the cause”, and it cannot conclude that “one Linux user can’t run two Remote Controls”. Below is the troubleshooting order I put together afterwards, along with the causes the official documentation lists for the command exiting.

Troubleshooting order: stop, read the logs, run by hand

Run the following from an admin account with sudo (the default ubuntu on Ubuntu). Running systemctl --user directly in a sudo -iu shell can give No medium found, so you need to point it at the user’s runtime directory and D-Bus (for why, see How to Fix systemctl –user No medium found).

Stop the failing one first

Restart=on-failure makes systemd keep retrying, so the logs get flooded with repeated starts, and a retry may also run at the same time as your manual test. Stop it first:

PROJECT_USER=project-a
SERVICE=claude-project-a-content.service
uid=$(id -u "$PROJECT_USER")

sudo -u "$PROJECT_USER" \
  XDG_RUNTIME_DIR="/run/user/$uid" \
  DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$uid/bus" \
  systemctl --user stop "$SERVICE"

Stop only the one that has the problem. Leave every other running Remote Control alone.

Read the recent logs

Don’t look only at the last few lines of status:

sudo -u "$PROJECT_USER" \
  XDG_RUNTIME_DIR="/run/user/$uid" \
  DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$uid/bus" \
  journalctl --user -u "$SERVICE" -n 100 --no-pager

The logs may contain environment URLs, session IDs or other internal information. Read through all of it before sharing it with anyone.

Run it by hand as the same user in the same directory

sudo -iu "$PROJECT_USER"
cd ~/projects/project-content
~/.local/bin/claude remote-control --name "Content Writer" --spawn=worktree

The working directory must match WorkingDirectory= in the unit file, and the arguments must match ExecStart=. If you see Enable Remote Control? (y/n) or Trust <directory>? [y/N] while running it by hand, check it and answer y. Once you see a successful connection and the environment shows up on your phone or the web, press Ctrl+C to end the manual process, exit that user, and start the systemd service.

If running it by hand also fails, keep the exact error text and compare it with the next section. The official documentation also offers two tools:

• claude remote-control --verbose: shows detailed connection and session logs. The official troubleshooting for “Remote credentials fetch failed” uses it to see the full error.
• claude doctor: prints diagnostics for the installation, settings files and Remote Control eligibility without opening a session, so you can see which eligibility check failed.

Exit causes listed in the official documentation

The table below is compiled from Claude Code’s Remote Control and error reference documentation (checked on 12 October 2026). The “Code” column gives the exit code only where the documentation states it explicitly; where the documentation only says it “exits with an error”, I don’t fill in a number.

Untrusted working directory: the easiest trap under systemd

According to the official documentation, when you run claude remote-control in a directory it has not trusted, it first explains what trusting the directory enables, then asks Trust <directory>? [y/N]. When standard input or output is not a terminal, it cannot ask, so it exits with a Workspace not trusted error and code 1. A systemd service has no terminal, which is exactly this situation.

The official fix is to trust the directory in a terminal first: run claude rc (an alias for claude remote-control) there and answer y, or run claude and accept the trust dialog, then go back and start the original command. Your home directory is the exception: trust is never remembered there, so start from a project directory instead.

I didn’t keep enough logs that time, so I can’t confirm whether this was the cause. But if your situation is “works by hand, fails under systemd”, or it started failing after you created a new working directory with git worktree add, this is the first thing worth checking: run every WorkingDirectory= by hand once, in a terminal, as the same user.

Login, plans and environment variables

• Not logged in, or not a subscription login: Remote Control supports the Pro, Max, Team and Enterprise plans, not API keys. The official fix is to run claude auth login and choose the claude.ai login.
• ANTHROPIC_API_KEY or ANTHROPIC_AUTH_TOKEN: the error message says which one it is. Remove it from your shell environment or from the env block of your settings file. A systemd service’s environment differs from your interactive shell, so check Environment= in the unit file as well.
• Team and Enterprise plans: an Owner has to turn on Remote Control in the Claude Code admin settings; it is off by default. If it is not on, you get an error related to organization policy.
• Plan just changed: the documentation recommends claude auth logout followed by claude auth login to refresh.
• Other environment variables: if ANTHROPIC_BASE_URL points to a host other than api.anthropic.com, or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC or DISABLE_GROWTHBOOK is set, Remote Control cannot be used.

Arguments in the wrong place

According to the official documentation, if you put global flags that affect the session, such as --settings or --permission-mode, before remote-control, Claude Code refuses to start and names the flag. Remote Control’s own flags go after remote-control; to set the permission mode, use claude remote-control --permission-mode <mode>.

Network down for about 10 minutes

In server mode, after the host has been awake but unable to reach the network for about 10 minutes, Claude Code gives up, the claude remote-control process exits, and you need to run it again. The documentation does not give an exit code for this case. Whether Restart=on-failure brings it back depends on how the process exits, so confirm it in the journal rather than assuming systemd handles every disconnection.

Works by hand, fails under systemd

Running by hand and running under systemd differ in these ways:

The official documentation does not say what Enable Remote Control? (y/n) does without a terminal; the safe approach, again, is to answer it by hand first.

What not to do

• Don’t keep running restart: activating (auto-restart) means systemd is already retrying. Restarting by hand over and over only makes the logs messier.
• Don’t guess the cause first: until you have the error text, don’t assume it is OAuth, the network or a concurrent session limit. The official --capacity is the limit on concurrent sessions, 32 by default; unless the error message points to it, don’t assume the limit is the problem.
• Don’t delete your login data and start over: before clearing ~/.claude/ or reauthorizing, make sure the error message really points to login.
• Don’t restart every service at once: deal only with the one that failed, so you don’t interrupt work running in other environments.
• Don’t post tokens: check logs and screenshots for URLs, tokens and session IDs first.

How to verify the fix

1. Once running it by hand succeeds, press Ctrl+C to end it. Don’t let the manual process and the service run at the same time.
2. Start the service; systemctl --user status shows active (running).
3. The logs contain a successful connection message and the --name you set.
4. The Claude app on your phone or claude.ai/code shows the environment, and you can start new work in it.
5. Close SSH completely and reconnect; the service is still running.
6. Pick a time when no important work is running, reboot, and confirm the service comes back on its own.

active (running) only proves the process exists; whether it actually connected is shown by the logs and the environment list. For the full steps for the server, installation and your first always-on service, see Running Claude Code Remote Control on a Free Oracle Cloud Server. For how to split users and worktrees when one server runs several environments, see Running Multiple Claude Code Remote Controls on One Server. For what to watch for when installing on an ARM64 server, see Installing Claude Code on ARM64: Can Oracle Ampere A1 Run It?.

FAQ

What does exit code 1 mean for Claude Code Remote Control?

When systemd shows code=exited, status=1/FAILURE, the claude remote-control process itself exited with code 1. In the systemd documentation, 1 is a generic failure and says nothing about the cause. To find the real cause, read the logs, or run it by hand as the same user in the same directory and look at the error message.

Why does it connect when I run it by hand but exit with code 1 under systemd?

One cause the official documentation spells out is that the working directory has not been trusted yet. In a directory it has not trusted, claude remote-control asks Trust <directory>? [y/N]. Under systemd there is no terminal to answer, so the command exits with a Workspace not trusted error and code 1. Other differences to compare include HOME, PATH, the working directory and login state.

Remote Control keeps showing status=1/FAILURE. What should I do first?

Stop the failing service first so systemd's retries don't get in the way of your diagnosis. Then read the last 100 lines of the log with journalctl --user, switch to the same Linux user and working directory, and run the same claude remote-control command by hand to get the exact error text.

How are status=200/CHDIR and 203/EXEC different from status=1?

200/CHDIR and 203/EXEC are systemd's own codes: 200 means changing to WorkingDirectory failed, and 203 means the program could not be executed, usually because the executable was not found. status=1 means claude had already started and then exited with a failure on its own.

Will setting ANTHROPIC_API_KEY make Remote Control fail to start?

You will get an error. The official documentation says Remote Control only supports claude.ai subscription login. When ANTHROPIC_API_KEY is set in the environment, you get Remote Control requires claude.ai subscription auth. Remove the variable from your shell environment or from the env block of your settings file, then log in with claude auth login.

Will a network outage make claude remote-control exit?

According to the official documentation, in server mode the claude remote-control process exits after the host has been unable to reach the network for about 10 minutes, and you need to run it again. Whether Restart=on-failure brings it back up after this kind of exit is something to confirm in the logs.