docs: remote-ssh hangs on a bare sudo — pipe it; record where the dsh update stopped

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

@@ -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 <cmd> | 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

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`