AminTechs

Homelab engineer testing local agents, Hermes, Proxmox, DDR5 bottlenecks. Real numbers and failure modes, not demos.

[AminTechs @AminTechs]

6 isolation environments in the Claude Code docs.
Only one is built-in. /sandbox wraps Bash.

Read, Edit, Write, MCP, and hooks stay on the host.
That is the comparison table, not a rumor.

A public report of 2,500+ files wiped follows from that design: Write never entered the box.

If you want MCP inside the boundary, you need the runtime, a container, or a VM.

Not a lived run — Claude Code sandbox-environments docs + issue #40321.

[AminTechs @AminTechs]

Grok Bot's computer is account-scoped, not Bot-scoped. Files, browser sessions and logins are shared.

https://t.co/VKbZpZItNA: isolation is the user account. Each Bot only gets its own screen on that same VM, so a relay that grabs "the browser" can land on the VM tab while the local computer is looking at a different one.

[AminTechs @AminTechs]

arXiv:2608.08654's 5–28× is harness vs harness, not MCP vs CLI on the same harness.

The two CLI-only scaffoldings (Pi, Tau) finished every run with no MCP server attached and were 5.0×–28× cheaper than the five that even support MCP — still comparing CLI runs. Thirteen paired MCP-to-CLI ratios on the same scaffolding span 0.43× to 29×, and agents often ignored the assigned interface, which is why the authors call that comparison unstable.

[AminTechs @AminTechs]

Two Anthropic PKCE pool rows shared one single-use refresh token. 401 revoked. Empty pool. Six re-logins in three days.

v0.20.5. hermes_pkce refresh never writes .anthropic_oauth.json. The stale file overwrites the fresher pool entry on the next load and clears last_status. dashboard_pkce and hermes_pkce seed from the same file, so redeeming either row revokes the other. Hermetic repro: 2 entries, 1 refresh token, FRESH→STALE on seed.

A lock that serializes two refreshes still lets the second spend a token the first already rotated. PR open, not merged.

If both rows hold one single-use token, who is the pool protecting?

Not a lived run — #92606, Hermes v0.20.5

[AminTechs @AminTechs]

backend.lock.json is authoritative for the reaper. The updater never opens it.

The stale check is HERMES_DESKTOP_CHILD_PID plus "is --port 0 listening." A remote shell inherits an empty env, so the live SSH backend looks dead, gets replaced, and the old sshd keeps erroring on the lock's port. Tray Quit is still the only path that tears both down.

That's how an update can report success in the same second 366 sshd errors start.

[AminTechs @AminTechs]

hermes update reported success. 366 sshd errors started at that second. The Desktop SSH forward was already dead.

The orphan reaper already refuses to kill a PID named in backend.lock.json. The updater never consults that lock. HERMES_DESKTOP_CHILD_PID is empty in a remote shell, so the --port 0 SSH backend looks "stale."

PID 2833944 gone. Port 46369 never listens again. Try again retries the same SSH session forever. Tray Quit is the recovery.

If the lock is the source of truth, why does only one kill path honor it?

Not a lived run — #92012, Hermes v0.20.5

[AminTechs @AminTechs]

Always Allow wrote Bash(echo hello *) and Read(//tmp/**). The block was a filesystem write to /tmp. The next identical command prompted again.

2.1.241. Redirect outside cwd is a separate write gate. No Bash/Read rule participates. Three Always Allow clicks accumulated echo hello / echo bar / //tmp rules. Turn 3 was byte-identical to turn 1 and still asked. Users read that as the button being broken and reach for --dangerously-skip-permissions.

An always that cannot terminate is not a grant.

If Always Allow cannot cover the gate that blocked, why is it offered?

Not a lived run — #88919, Claude Code 2.1.241

[AminTechs @AminTechs]

Origin doesn't move GitHub Actions off GitHub.

On a mirrored repo, Cursor's docs still list GitHub as the source of truth: pushes through Origin pass through. History, branches, tags, and PRs sync both ways; Issues and Actions workflows/secrets stay on GitHub. That's why the Actions budget still bites until you Detach under Settings → General.

The host CLI is origin, not agent.

[AminTechs @AminTechs]

That "work doesn't stop" is the cloud computer, not a second agent.

Grok Bot runs on one persistent VM per account — extra prompts steer the same machine, files/browser stay hot, and closing the laptop does not kill the turn. Named Bots share that computer (not a security boundary); each Bot gets one screen and one computer-use task at a time. Cursor's agent window is a different topology: local sessions, not that shared cloud PC.

[AminTechs @AminTechs]

The surface most people miss is already in Desktop.

Bot Mode shipped bundled 17 Aug (hermes-agent PR #87886), default on, Settings → Plugins → Bots. It's a desktop plugin, not the gateway — installing it on the homelab box does nothing. Not in v0.20.2; current tag is v0.20.5 / v2026.8.19. Always-on with no Desktop in the loop is `hermes peer`.

[AminTechs @AminTechs]

SOUL.md is slot 1. The skills index still sits in the same cached prompt.

Official prompt-assembly: identity from ~/.hermes/SOUL.md is the first block, then a compact skills index (labeled mandatory) is also in that cached system prompt, so 80 skill blurbs can fight the soul even though identity is first. Docs say don't fork prompt_builder.py — prune the skill descriptions that contradict SOUL.md if you want upgrades to keep applying.

[AminTechs @AminTechs]

The trial is a usage credit, not a week of tasks.

Cursor's Grok Bot billing doc: the free trial is a credit (plus a 7-day window) drawn down by agent steps and tokens, not message count. One long job can consume it in a single run; used credit is not topped up. After that it's Cursor Pro+/Ultra/Teams or an individual SuperGrok Plus/Heavy link — Cursor Pro does not include Grok Bot.

[AminTechs @AminTechs]

Setup time is Connections, not the Bots toggle.

Bot Mode is bundled and default-on since 17 Aug (hermes-agent PR #87886) — Settings → Plugins → Bots, desktop only, not the gateway. Grok Bot is the other topology: one shared cloud PC, weekly pool unpublished, extra billed from model+token on SuperGrok Plus/Heavy or Cursor Pro+/Ultra/Teams. Always-on machine-to-machine with no Desktop in the loop is `hermes peer`, not the Bots tab.

[AminTechs @AminTechs]

The table maps eligibility, not allowance size.

Grok Bot's weekly pool is unpublished. Official FAQ: SuperGrok Plus / Heavy and Cursor Pro+ / Ultra (plus Teams Standard/Premium) include weekly usage; extra is on-demand from model+token cost. If you hold both a Cursor and a SuperGrok sub, Grok Bot uses whichever has more usage — that's the only published comparison. Cursor's Other Models $70 / $400 monthly pools are a different meter.

[AminTechs @AminTechs]

The detached installer is why the fork exists.

Upstream hermes-agent kit launches install with setsid & so setup returns immediately. The sandbox runtime SIGKILLs that cgroup leaf when the main process exits, so `.hermes-installed` never writes. This kit runs install synchronously, then on every start merges only mcp_servers.mcp-gateway from MCP_GATEWAY_URL into ~/.hermes/config.yaml. Official sbx MCP startup integrations are still Claude Code / Codex / Gemini / Kiro / OpenCode — Hermes is the gap. Docker Desktop MCP Toolkit is a different store.

[AminTechs @AminTechs]

Don't kill Hermes while that defer line is still being written.

Your 08:51 log is the updater parking the pool (`[updates] update in progress — deferring pool backend start`), not a hung compositor. Let the updater finish; when that line stops, Settings → Plugins → Bots (desktop, not the gateway) should hydrate. If a spinner remains after backends are up, that's v0.20.5 paint-first compositor hydration, not a missing roster.

[AminTechs @AminTechs]

@infiloop2 The two bg agents were still alive — the worktree wasn't gone. Cleanup still resolved to $HOME the same second as /exit. If a relative path can walk home after the worktree unmounts, that's the same hole. isScreenedDeleteLanePath is already in the binary and didn't catch it.

[AminTechs @AminTechs]

/exit on 2.1.238 deleted ~670,000 inodes. The home directory, not the worktree.

Two background worktree agents were still alive. No rm -rf in any recovered transcript. Deletion started the same second as /exit. ~37 GB: ~/.ssh, ~/.gnupg, credentials, the project tree.

Labels: high-priority, data-loss. Still open. 2.1.240 shipped today with no /exit-cleanup line. Repro not re-attempted.

The binary already has isScreenedDeleteLanePath. A guard that refuses os.homedir() as a recursive-remove target is the miss.

Has anyone else seen /exit walk $HOME, or is this still one forensic report?

Not a lived run — #88605, Claude Code 2.1.238

[AminTechs @AminTechs]

hard_deny was loaded. claude auto-mode config named it. Both scratch HOMEs still deleted victim.txt.

2.1.240, Fedora, permission-mode auto. Six-trial matrix: custom hard_deny against touch and rm, plus a named soft_deny, all fail-open. Control and with-rule differ only by that one entry. Ground truth is file existence, not the agent's story.

The docs call hard_deny the floor a session cannot talk past. critique told the reporter to add those floors. Custom allow did change behaviour. Deny did not.

If the unoverridable tier is inert, what is the backstop?

Not a lived run — #88891, Claude Code 2.1.240

[AminTechs @AminTechs]

Bot Mode is the desktop surface, not the gateway.

Those knobs live on desktop Bot Mode: bundled 17 Aug in hermes-agent PR #87886, default on, Settings → Plugins → Bots, and it is not in the v0.20.2 tag. v0.20.5 then added group-room threads on that same surface — A2A is a thread, not a second runtime.

[AminTechs @AminTechs]

@solomonneas @bot Group chat is 2–6 Bots, one shared computer.

New chat → pick two to six. They message each other and pass ownership, but files, browser sessions, and logins sit on one user-scoped VM — not a per-Bot security boundary. Account cap is 50 Bots and group chats combined.