[Bug] Desktop app SSH connections fail because PTY is not allocated when invoking remote `claude`

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

The Claude Code desktop app's SSH connection feature fails to establish working sessions with remote hosts because it invokes claude over SSH without allocating a pseudo-terminal (PTY). Without a TTY, the remote claude process falls back to --print mode, which requires stdin or a prompt argument; receiving neither, it exits immediately with the error:

Warning: no stdin data received in 3s, proceeding without it.
Error: Input must be provided either through stdin or as a prompt argument when using --print

The SSH connection itself, key authentication, and PATH resolution are all working correctly. The bug is specifically that the app's underlying SSH invocation is missing the equivalent of ssh -t.

On the remote host, /var/log/auth.log shows the symptom clearly:

sshd[6736]: pam_unix(sshd:session): session opened for user Doyeon by (uid=0)
sshd[6736]: pam_unix(sshd:session): session closed for user Doyeon

session opened immediately followed by session closed — the SSH session establishes successfully, then the remote claude process dies right away because of the missing TTY.

Verification That Other Causes Are Ruled Out

• TCP reachability: confirmed (ssh user@host from terminal works)
• Host key: known_hosts populated
• Key authentication: succeeds (PAM session opens)
• Non-standard port (6069): not the cause
• PATH resolution: ssh host "claude --version" returns 2.1.109 (Claude Code)
• Single-shot exec: ssh host "echo HELLO && claude --version && echo DONE" returns all three lines with exit code 0

The only difference between the failing case (ssh host "claude") and the working case (ssh -t host "claude") is PTY allocation.

Possibly Related Issues

#48428 (filed by me earlier with an incorrect ssh2/Windows/non-standard-port hypothesis — please disregard that diagnosis), #35073, #48241, #48140 — likely the same root cause.

Secondary UX Issue

The app should surface the underlying remote error rather than failing silently. As it stands, the failure mode gave no clue this was a TTY issue, leading to hours of misdirected debugging.

What Should Happen?

When the desktop app invokes claude on a remote host via SSH, it should request PTY allocation (equivalent to ssh -t), since claude is an interactive program by default. The remote Claude Code REPL should launch and the desktop app should connect to it successfully.

Suggested fix: in the underlying SSH client (likely ssh2 for Node.js), set pty: true when opening the exec channel for the remote claude invocation.

Error Messages/Logs

# Remote /var/log/auth.log on each connection attempt from the desktop app:
sshd[6736]: pam_unix(sshd:session): session opened for user Doyeon by (uid=0)
sshd[6736]: pam_unix(sshd:session): session closed for user Doyeon
sshd[6752]: pam_unix(sshd:session): session opened for user Doyeon by (uid=0)
sshd[6752]: pam_unix(sshd:session): session closed for user Doyeon
sshd[6765]: pam_unix(sshd:session): session opened for user Doyeon by (uid=0)
sshd[6765]: pam_unix(sshd:session): session closed for user Doyeon

# Reproducing what the app does manually:
$ ssh user@host "claude"
Warning: no stdin data received in 3s, proceeding without it. If piping from a slow command, redirect stdin explicitly:
< /dev/null to skip, or wait longer.
Error: Input must be provided either through stdin or as a prompt argument when using --print

# Same command with -t (PTY allocation) works correctly:
$ ssh -t user@host "claude"
# → Interactive Claude Code REPL launches successfully

Steps to Reproduce

1. On a remote host (e.g., Linux server, NAS), install Claude Code and ensure claude is resolvable in $PATH for non-interactive SSH sessions. Verify with: ssh user@host "claude --version" → should return version string.

1. In the Claude Code desktop app on Windows, open SSH connection settings and add a new connection:

• Host: user@host (or an alias from ~/.ssh/config)
• Port: any (tested with non-standard port 6069, but port is not the cause)
• Identity File: path to working SSH key

1. Click "Add SSH connection" and attempt to connect.

1. Observe: connection fails. The desktop app reports a generic connection error.

1. On the remote host, check /var/log/auth.log (or equivalent). You will see session opened immediately followed by session closed for each connection attempt — confirming SSH establishes successfully but the remote process dies immediately.

1. To confirm the root cause, manually run from the same Windows client:

• ssh user@host "claude" → reproduces the failure (Error: Input must be provided...)
• ssh -t user@host "claude" → works correctly (REPL launches)

The only difference is the -t flag forcing PTY allocation. The desktop app is not requesting a PTY when it should.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.109 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment Details

• Client: Windows 11
• Client SSH: OpenSSH 9.5p2 (C:\Windows\System32\OpenSSH\ssh.exe)
• Remote: Synology DSM (NAS), OpenSSH 8.2
• SSH port: 6069 (non-standard, but verified not to be the cause)
• Auth: ed25519 key, no passphrase
• Remote Node.js: v20.19.5
• Remote claude: /var/services/homes/Doyeon/.local/bin/claude, symlinked to /usr/bin/claude

Note on Related Issue #48428

I previously filed #48428 with the hypothesis that this was an ssh2 library bug related to Windows + non-standard ports. After deeper investigation (PowerShell-side reproduction comparing ssh vs ssh -t), that hypothesis was wrong. This issue contains the correct diagnosis. I will close #48428 with a reference to this issue.