From f44b8aa1cf9757b9821107f392bd4ee2e2082c5a Mon Sep 17 00:00:00 2001 From: Vuong Hoang Date: Sat, 5 Sep 2026 08:37:56 -0700 Subject: [PATCH] =?UTF-8?q?docs:=20remote-ssh=20hangs=20on=20a=20bare=20su?= =?UTF-8?q?do=20=E2=80=94=20pipe=20it;=20record=20where=20the=20dsh=20upda?= =?UTF-8?q?te=20stopped?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Found by using the tool for real work rather than by smoke-testing it. A bare `sudo -n whoami` through ssh_run returns `running` with no output and wedges the session permanently; the same command piped through `cat` returns everything. Reproduced on both macOS and Debian, so it is the harness rather than a platform quirk, and it matters because infra work is sudo work. The workaround goes in CLAUDE.md where a session will actually hit it. The proper fix is a protocol change — run the command through a pipe and read PIPESTATUS — and is deliberately not attempted here. Also records where the dsh work stopped: the package is updated but the running web process is still on the old code, left alive on purpose because there is no LaunchAgent to restart it into. --- CLAUDE.md | 8 ++++++++ persistent-memory.md | 27 +++++++++++++++++++++++++++ 2 files changed, 35 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index 8327286..729ade8 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -62,6 +62,14 @@ It deliberately has **no file transfer and no idempotency**; that is elway's hal agreement; coordinate before touching, which is a contractual posture and not a security one. `pfi-pve` (10.250.250.31) is deliberately NOT caught by this — the denies are host-specific, not a /24 over shared space. +- ⚠⚠ **A bare `sudo` HANGS the session — always pipe it: `sudo -n | cat`.** + `ssh_run 'sudo -n whoami'` returns `running` forever with zero output and the + session is then permanently `busy`; the piped form returns everything. Measured + on both macOS and Debian, so it is the harness and not a platform quirk. Cause: + sudo ≥1.9.14 defaults `use_pty` on and relays through its own PTY; with the run + frame's stdin on `/dev/null` and stdout on the session PTY the relay never + completes, so the completion marker never arrives. A pipe makes stdout a non-tty + and sudo skips the PTY. Not yet fixed in our fork. **Task visibility via task-board.** If the Claude Code session has the `task-board` plugin enabled (installed from diff --git a/persistent-memory.md b/persistent-memory.md index 3c26e93..d76072d 100644 --- a/persistent-memory.md +++ b/persistent-memory.md @@ -377,6 +377,33 @@ below is a live commitment or a known-open risk._ operator verb. Relevant to the pending `ledger-dev` → `svos-dev` rename, which is still the operator's call. nh3-dev not yet upgraded. +- ⚠ **`remote-ssh` MCP: a bare `sudo` hangs the session forever — pipe it.** + `ssh_run 'sudo -n whoami'` returns `running` with EMPTY stdout and the session is + then permanently `busy`; `sudo -n id | cat` works and returns everything. + **Measured on BOTH macOS 26.6 and Debian (nh3-extdev), so it is the tool, not a + platform quirk.** Cause: sudo ≥1.9.14 defaults `use_pty` on and relays through + its own PTY; the run frame gives the command stdin on `/dev/null` while stdout + stays on the session PTY, the relay never completes, and the completion marker + never arrives. Workaround `| cat` is in CLAUDE.md. **The proper fix is unbuilt** + — likely running the command through a pipe inside the run frame and taking the + exit code from `PIPESTATUS`, which is a real protocol change (commands lose tty + detection) and wants its own red-green cycle. Matters more than it sounds: infra + work is sudo work, and this was found by USING the tool, not by smoke-testing it. + +- **`dsh` on `esh-macbook-air` updated 0.1.1-rc.2 → 0.1.2-rc.1** (2026-09-05; + latest published 2026-09-03). Global install and the shared profile tree both + confirmed on the new version. ⚠ **The RUNNING `dsh web` (pid 16231, up since + Wed 4pm, 127.0.0.1:3080) is still on the OLD code and was deliberately NOT + killed** — there is no LaunchAgent, so killing it would have left nothing + running rather than a restarted service. It runs as a FOREGROUND process in the + operator's terminal (`s005`, `S+`): it dies with the terminal and does not + survive a reboot, which is the real fragility. A `com.pfi.dsh-web` LaunchAgent + was drafted but **the privileged write was blocked by the permission + classifier** — base64 piped into `sudo tee` of a LaunchAgent is a malware-shaped + pattern and the block is correct; it needs operator approval or an operator-run + install. Bind stays `127.0.0.1` deliberately: widening it is a security decision + on a personal laptop whose application firewall is off, and not mine to take. + ## Recent decisions - `[2026-09-05]` **A peer's "2.7x serving-stack effect" was a coin flip — the operator rejected it on instinct and the arithmetic backed him.** Each floor was `|b0-b1|` from n=2; the ratio is half-Cauchy, P=0.452. ⚠ The disconfirming evidence sat in brokkr's own sentence, and he named *why*: the claim was his and flattering. → `persistent-memory.d/2026-09-05-floor-claim-n2-retraction.md`