[BUG] Claude Science: SSH password card never re-fires after the held password expires (password-only host)

Related (closed/locked, same failure shape in Claude Code CLI): anthropics/claude-code#17223
"SSH passphrase prompts no longer appear when running SSH commands via Bash tool".

Summary

For an SSH compute target that only accepts password / keyboard-interactive authentication,
the first connection after creating the target correctly shows the password card. Once the
in-memory password expires (~8 h) or the session is reset, every subsequent connection
attempt fails immediately with Permission denied and no password card is offered. The
Compute panel's own guidance — "Ask the agent to connect to this host from a conversation
(for example: run true on it) and you'll be prompted for the password right there" —
does not hold: running true, hostname, or any other command returns exit 255 with no
prompt, from both the persistent REPL kernel and fresh ephemeral kernels, and via both
call_command and submit_job.

The only recovery that has worked is deleting the target and re-adding it in Customize →
Compute, after which the first command shows the card again. Over two working days this
cost roughly one full day of dead time across ~8 expiry cycles.

Environment

• Claude Science, Windows 11 host (native, PowerShell), sandboxed agent.
• Two SSH targets on a university HPC (Slurm): agent-easley and agent-hopper, same

account, same behaviour on both.

• Server auth offer (from the error string): publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive.

Public-key auth is refused server-side for this account; password is the only working method.

• Password is held in memory only ("about 8 hours, never saved").

Steps to reproduce

1. Create an SSH compute target for a host that accepts password auth only.
2. In a conversation, run any command on it (c = host.compute.create('target'); c.call_command('true', intent=...)).

→ Password card appears, user enters password, command succeeds. OK.

1. Wait for the held password to expire (~8 h), or let the session idle-reset (kernels shut down).
2. Run the same command again.

→ Returns exit 255, stderr user@host: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive).
No password card is shown. host.credentials.list() returns [].

1. Repeat from a fresh ephemeral kernel, from the primary kernel, via submit_job: identical.
2. In Customize → Compute, "re-enter credentials" on the existing target: no effect.
3. Delete the target and re-add it with the same host/user; run true → card appears, works.

Observed 29–30 Sep 2026, at least eight independent expiry events, 100% reproducible.

Expected

A connection attempt with no held password on a password-auth host should raise the
password card (as it does on first connect), exactly as the panel text says.

Secondary issue (same host, likely related)

After the password card is answered on a recreated target, c.download() / c.upload()
fail indefinitely with
Provider 'ssh:agent-easley' has no scratch_root configured yet. It is set automatically by the connection probe.
The probe apparently uses key auth, which this server refuses, so it never completes and
scratch_root is never set. call_command works throughout. Net effect: no file transfer
in either direction for the life of the target; we shuttle files as base64 through command
stdout (which itself is truncated at 65,536 characters with an ellipsis — a third, minor
issue worth documenting for the call_command API).

Impact

Any multi-hour or overnight workflow on a password-only cluster stalls at the next expiry
until a human recreates the target. Long-running experiment supervision is not possible.

Suggested fixes (any one would suffice)

• Trigger the password card whenever an SSH attempt fails with Permission denied and

password/keyboard-interactive is in the server's offered methods and no credential is held.

• Make the panel's "re-enter credentials" action actually re-arm the card / set the password.
• Allow the connection probe to fall back to the held password (fixes scratch_root too).
• Offer a configurable password lifetime for hosts the user marks as trusted.