--- name: hostinger-web-terminal-ops description: Hand Rob paste-safe command blocks for the Hostinger web terminal — his ONLY VPS admin path (no SSH from Windows). Use whenever a task requires him to run commands himself (secrets setup, authorize clicks). Covers the hard-wrap paste pitfall that silently breaks long one-liners. --- # Hostinger web terminal ops Rob administers the VPS (robshermes / 2.25.172.164) through the Hostinger web terminal in a browser tab — there is no SSH from Windows. When a step needs HIS hands (fetching secrets from a web UI, clicking authorize in an OAuth flow), you hand him command blocks to paste. ## Command-block rules (hard-won) 1. ONE code block per message, headed "copy and paste this whole block" — he pastes messages wholesale. 2. **Every line short and fully self-contained.** The web terminal hard-wraps long pasted lines: a wrapped `&&` chain or long `sed`/`printf` one-liner arrives split into a broken partial command plus the remainder executed as garbage — classic signatures: `sed: no input files`, and the target filename landing on its own line → `-bash: /path/to/file: Permission denied`. Broke twice in one session (2026-07-29). Prefer several short `echo '...' >> file` lines over one long pipeline or sed. 3. End the block with a verification command he can read back (`systemctl is-active X`, `cat file`) — you cannot see his screen. 4. A stray `─ bash` line (his terminal chrome) pastes as `─: command not found` — harmless. Tell him to ignore it, not re-paste in a panic. 5. Secrets warning UPFRONT, before the block: what lands where, perms (chmod 600 under `/root/.hermes/secrets/`). 6. If real secrets land in the chat instead of the terminal: note that chat history now holds them, offer regenerate-then-update-the-file-directly as cleanup, don't force it. ## Recovering from a mangled paste Nothing usually executes (the fragments error out), so don't assume partial state — verify with `cat`/reads before re-handing the fixed block. Re-issue as separate short lines, not a repaired long one. ## Paste METHOD matters (hit live 2026-08-03) **Right-click paste ≠ Ctrl+V in the Hostinger web terminal.** Right-click paste mangles content: whole multi-line blocks can vanish silently (no output, nothing executed), URLs inside quotes get eaten (`https://...` line arrives as `''` and leaves bash hung at a `>` continuation prompt — the "flashing cursor" symptom), and quote characters corrupt. Ctrl+V paste is reliable. If Rob reports "nothing happened" or a hung cursor after pasting, FIRST question: "right-click or Ctrl+V?" Recovery from a hung `>` continuation: Ctrl+C, verify with `echo hi`, then re-run. A sanity probe that fits the terminal: `printf 'test\n' > /tmp/qtest` then `cat /tmp/qtest` — confirms quotes survive before re-sending the real block. Also: URLs inside pasted quoted strings are the highest-risk content; consider `echo "VAR=https://..." >> file` (double quotes survived better than the printf '%s\n' pattern in practice) and always have him `cat` the target file before any `systemctl restart` consumes it. ## Alternative when the terminal fights back: agent-side file writes If paste fails repeatedly on a file the agent can write (anything under /root/.hermes), stop burning cycles — write the file directly with the write_file tool (secrets already in session can be placed, with the standard "rotate later" hygiene note), then have Rob run only the trivial tail commands (`chmod`, `systemctl restart`, `curl` health check). One-line commands paste far more reliably than multi-line blocks. Reserve his terminal time for steps that genuinely need his browser/credentials. **Escalate to this FAST — user correction 2026-08-03: "in the future, jump to that solution ALOT faster."** Don't iterate paste attempts more than ONCE. The sequence that wastes his patience: block paste fails → re-issue as separate lines → lines mangle → retry with different quoting → … Instead: ONE paste failure → offer the agent-side write immediately. Especially for secrets/env files: the values are usually already in the session by that point, so the agent can compose the file itself and leave Rob a single `systemctl restart` + health check. His terminal time is the bottleneck resource — treat paste failure #2 as the hard trigger, not the last resort. ## Never hand Rob nano/vi — editor-free edits only (2026-08-06) When a file edit genuinely needs his hands (e.g. config.yaml, which the agent's patch/write tools refuse), do NOT walk him through an interactive editor. Tried nano tonight: Ctrl+W/Ctrl+X keystrokes didn't register (the web terminal needs a mouse click for keyboard focus, and even that was flaky), the file accrued an unsaved-changes asterisk from a stray keypress, and he reported "not comfortable here." **The pattern that worked: a single sed one-liner + a grep verify in one paste block.** Rules: - Make the edit a `sed -i 's|old|new|' file` (use `|` delimiters — the content often contains `/` and `"`), followed immediately by a `grep -A N` that prints the changed region so he can eyeball it. - Mind the hard-wrap rule: if the sed line is long, it's safer to write the file agent-side when possible and leave him only `systemctl restart`. - If he's already stuck INSIDE an editor: click black terminal area for focus → Ctrl+X → answer N to "Save modified buffer?" → verify he's out. Nuclear option: close the browser tab; nano dies with the session, nothing saves. - Keyboard shortcuts in general are unreliable in this terminal (focus-dependent) — design every interaction as paste-a-block, press-Enter, read-output. ## crontab via web terminal (worked 2026-08-06) Adding a cron line is paste-safe if the whole thing is ONE block: `(crontab -l 2>/dev/null; echo "*/30 * * * * /path/to/script.sh >/dev/null 2>&1") | crontab -` followed by `crontab -l | tail -3` as the verify. If `tail -3` shows only the new line, his crontab was previously empty — that's expected, not data loss. ## "I need a Step 1" — sequence handoffs for Rob explicitly (2026-08-06) Multi-step procedures handed to Rob must be numbered ONE step per message with a clear completion check, and each step must state WHERE it happens (Hostinger terminal vs File Explorer vs Claude Desktop). Session evidence: after a dense 3-part instruction (find vault path → verify sync → attach in Cowork) he replied "I need a Step 1." The pattern that worked: "Step 1: open File Explorer, go to X, confirm you see Y — tell me when done" then wait. Don't chain Step 2/3 into the same message; he processes one action at a time, late at night, across multiple apps. Also: when a task spans his Windows machine and the VPS, say "Hostinger terminal?" is his standing confusion — answer it unprompted in every handoff ("this goes in the Hostinger web terminal" / "this is File Explorer on Connie").