[BUG] Remote SSH fails with NO_HOME on hosts lacking printenv (BusyBox/NAS devices) — probe should use echo "$HOME"

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

Claude Desktop's remote SSH feature ("connect to a remote host") fails during the post-authentication host probe on any remote whose shell environment lacks a printenv command (e.g. BusyBox-based / embedded Linux systems). SSH authentication succeeds fully; the connection then fails with:

Couldn't inspect the remote machine: couldn't determine the remote home directory [NO_HOME]

Root cause

The remote host-inspection probe determines the home directory by running printenv HOME and parsing the value between its __PRB2__ / __PRB3__ markers. On hosts without printenv, that command returns exit 127 (command not found) and produces no stdout, so the parsed home directory is empty, which triggers:

DeployError { phase: "probe", code: "NO_HOME" }

The same probe's other commands (uname -sm, id -u) succeed — only printenv is unavailable. printenv is a GNU coreutils utility and is not guaranteed by POSIX; BusyBox omits it in many builds, so remotes that are otherwise perfectly standard POSIX hosts fail.

Environment

• Remote: QNAP NAS — QTS 5.2.9, kernel 5.10.60-qnap, x86_64
• Remote shell: /bin/sh is GNU bash 3.2.57; system also ships BusyBox v1.24.1 (no printenv applet)
• Remote SSH server: OpenSSH_10.3p1
• Client: Claude Desktop (macOS), app version 1.22209.3, bundled Claude Code 2.1.216
• Auth: publickey via 1Password SSH agent (works — unrelated to the failure)

Steps to reproduce

1. On a Linux host without printenv on the default non-interactive PATH (a stock QNAP NAS reproduces this reliably), create a user with key-based SSH access.
2. In Claude Desktop, add that host as a remote and connect.
3. Auth succeeds; the connection then fails with NO_HOME.

Confirming the cause

Running the probe's own command over SSH shows the empty HOME:

$ ssh host 'echo __PRB1__; printenv HOME || true; echo __PRB2__; uname -sm'
__PRB1__
sh: printenv: command not found
__PRB2__
Linux x86_64

Suggested fix

Read the remote home without depending on printenv. Any of:

• Use echo "$HOME" (or printf '%s\n' "$HOME") in the same probe script — it's a shell builtin and works everywhere the probe already assumes a POSIX shell; or
• Fall back to getent passwd "$(id -un)" or SFTP realpath "." when printenv is absent.

Workaround

Installed a small POSIX printenv shim into a system PATH dir (/usr/bin/printenv) so the probe resolves:

#!/bin/sh
if [ $# -eq 0 ]; then exec env; fi
eval "val=\${$1}"
[ -n "$val" ] || exit 1
printf "%s\n" "$val"

On QNAP, /usr/bin is a RAM tmpfs restored from firmware at boot, so the shim must be recreated on startup via autorun.sh. (Note the app's non-interactive exec uses PATH=/usr/bin:/bin:/usr/sbin:/sbin and does not source .bashrc/.profile, so the shim must live in a system dir, not the user's home.)

Relevant client logs

From ~/Library/Logs/Claude/ssh.log and main.log:

[SSH2Connection] Connected to <user>@<host>:22
[RemoteServerController] Connection failed (~300ms, trigger: send_message): Couldn't inspect the remote machine: couldn't determine the remote home directory [NO_HOME]
LocalSessions.resolveSSHSettings ... DeployError ... phase:'probe', code:'NO_HOME', sshAuthMethod:'publickey'

What Should Happen?

When connecting to a remote host over SSH, Claude Code should correctly determine the remote home directory and establish the connection — including on hosts whose shell environment lacks the printenv command (e.g. QNAP QTS and other BusyBox-based / embedded Linux systems).

The home-directory probe should not depend on printenv (a GNU coreutils tool that isn't guaranteed by POSIX). Reading $HOME via a shell builtin such as echo "$HOME" works on every POSIX shell the probe already assumes, and would let these otherwise-standard hosts connect.

Error Messages/Logs

Client logs from ~/Library/Logs/Claude/ssh.log and main.log:

[SSH2Connection] Connected to <user>@<host>:22
[RemoteServerController] Connection failed (~300ms, trigger: send_message): Couldn't inspect the remote machine: couldn't determine the remote home directory [NO_HOME]

[main] LocalSessions.resolveSSHSettings fell back to local cascade for <user>@<host>: Couldn't inspect the remote machine: couldn't determine the remote home directory [NO_HOME]
  DeployError: phase: 'probe', code: 'NO_HOME', terminal: false, sshAuthMethod: 'publickey'

Running the probe's own command over SSH shows why HOME comes back empty:

$ ssh <host> 'echo __PRB1__; printenv HOME || true; echo __PRB2__; uname -sm'
__PRB1__
sh: printenv: command not found
__PRB2__
Linux x86_64

Steps to Reproduce

This does not involve Claude authoring code — it's the Desktop app's "connect to a remote host over SSH" feature failing before a session can start. Repro needs a remote host that lacks printenv on its default non-interactive PATH (a stock QNAP NAS reproduces it reliably; any BusyBox-based host without the printenv applet works).

1. On such a host, create a user with key-based SSH access. Confirm plain SSH works:

ssh user@host 'echo hi' → succeeds.

1. Verify the host has no printenv:

ssh user@host 'printenv HOME' → sh: printenv: command not found (exit 127).

1. In Claude Desktop, add that host as a remote (Remote SSH) and connect.
2. Observe: SSH authentication succeeds (logs show USERAUTH_SUCCESS / Connected to user@host:22), then the connection fails ~300 ms later with:

Couldn't inspect the remote machine: couldn't determine the remote home directory [NO_HOME]

Root cause: the post-auth host-inspection probe reads the remote home via printenv HOME, parsing the value between its __PRB2__/__PRB3__ markers. With no printenv, that yields an empty home → DeployError{ phase:"probe", code:"NO_HOME" }. The probe's other commands (uname -sm, id -u) succeed — only printenv is missing.

Workaround that confirms the diagnosis: installing a POSIX printenv shim into a system PATH dir (/usr/bin/printenv) makes the connection succeed immediately (logs then show Remote: home=..., platform=linux-amd64, shell=posix → Bridge channel opened). Fix on your side: read $HOME with a shell builtin (echo "$HOME") instead of printenv.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.216

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_