heavy-duty/box
7
0
Fork 1
Code Issues 9 Pull requests Projects Releases 4 Packages Wiki Activity Actions
box/templates/grok/user-data.yaml

76 lines
3.3 KiB
YAML
Raw Normal View History

feat: codex and grok templates — the mechanic's second and third tenants Two coding-CLI templates mirroring claude's shape: a box.env + verbatim cloud-init, inheriting the box-net placement contract structurally, no new design. - codex: OpenAI Codex CLI via 'npm i -g @openai/codex' (the SCOPED package; needs Node 22), symlinked onto the non-interactive exec PATH via 'npm prefix -g' — the same PATH fix the claude template needed. - grok: xAI Grok Build via the official 'curl x.ai/cli/install.sh', run AS the grok user (the installer drops into $HOME); the binary is found and symlinked to /usr/local/bin. Install commands verified upstream at implementation time, per the issue's rule (npmjs.com/package/@openai/codex, x.ai/cli). Each gets an AGENTS.md-style context file telling the agent it lives in a disposable, isolated, creds-free box. Drill: templates listing now expects four; a compact per-template smoke (mint, '<cli> --version' via box exec, remove) validates each payload installs and lands on the exec PATH — the generic mechanic is already proven by blank+claude and not repeated. Closes #54
2026-07-14 15:59:39 +00:00
#cloud-config
users:
- name: grok
shell: /bin/bash
sudo: "ALL=(ALL) NOPASSWD:ALL"
lock_passwd: true
write_files:
- path: /home/grok/.grok/AGENTS.md
owner: "grok:grok"
permissions: '0644'
defer: true
content: |
# You are running inside a box (template: grok)
A box is a trust-less, network-isolated, ephemeral VM created by the
`box` CLI. Keep this context in mind:
- **Creds-free by default.** The box starts with no xAI and no git
credentials. If you need to authenticate, the operator runs
fix(grok): read the actual installer instead of guessing — the binary is 'grok' Fetched https://x.ai/cli/install.sh and read it, rather than inferring the layout from docs. Three facts, every one of which the template had wrong: · the CLI installs as 'grok' (with an 'agent' alias) — NOT 'grok-build'. So the drill was checking a command that never existed. · BIN_DIR defaults to $HOME/.grok/bin, and what lands there is a SYMLINK into the versioned download dir — which is exactly why the template's 'find -type f' found nothing. · GROK_BIN_DIR can override the directory. The install was almost certainly succeeding the whole time; the template was hunting for the wrong name, as the wrong file type, in the wrong place. Now it links the known path onto the system PATH, asserts 'grok --version' answers, and dumps what the installer actually left if the upstream layout ever moves. Also corrected: the drill's version check (grok, not grok-build), the agent briefing ('grok login'), the template description, and the README row. The lesson is the repo's oldest one — read the thing, don't reason about it.
2026-07-14 20:04:10 +00:00
`grok login` interactively (SuperGrok / X Premium+). For git, the
feat: codex and grok templates — the mechanic's second and third tenants Two coding-CLI templates mirroring claude's shape: a box.env + verbatim cloud-init, inheriting the box-net placement contract structurally, no new design. - codex: OpenAI Codex CLI via 'npm i -g @openai/codex' (the SCOPED package; needs Node 22), symlinked onto the non-interactive exec PATH via 'npm prefix -g' — the same PATH fix the claude template needed. - grok: xAI Grok Build via the official 'curl x.ai/cli/install.sh', run AS the grok user (the installer drops into $HOME); the binary is found and symlinked to /usr/local/bin. Install commands verified upstream at implementation time, per the issue's rule (npmjs.com/package/@openai/codex, x.ai/cli). Each gets an AGENTS.md-style context file telling the agent it lives in a disposable, isolated, creds-free box. Drill: templates listing now expects four; a compact per-template smoke (mint, '<cli> --version' via box exec, remove) validates each payload installs and lands on the exec PATH — the generic mechanic is already proven by blank+claude and not repeated. Closes #54
2026-07-14 15:59:39 +00:00
operator adds their own credentials (a PAT or `gh auth login`). Never
assume credentials are present; never ask for or store secrets on disk
beyond what the operator sets up.
- **Isolated.** The box reaches the public internet but nothing on the host
or local network. There is no inbound path.
- **Disposable.** Nothing here is backed up. State is discarded when the box
is removed; the operator persists work via git push and via `box snapshot`.
- **Bootstrap runbook.** If the repository you are working in contains a
feat: host lifecycle as verbs (setup-host/teardown-host/migrate-host) + .box/ convention Two things: 1. The host scripts are first-class verbs now — 'box setup-host', 'box teardown-host [--purge-incus]', 'box migrate-host --box <n>'. Nobody should have to run ~/.local/share/box/host/<script>.sh; that read like an external script and exposed an install path. Each verb execs the installed script with its flags passed through (same pattern as 'box doctor'). README, doctor hints, and the uninstall section point at the verbs now. 2. The repo-runbook convention is '.box/', not '.claudebox/'. Renamed across docs and the templates' agent briefing; the briefing tells the agent to read either, and box-recipe.md notes the rename, so repos still shipping '.claudebox/' keep working through the transition. (Consuming repos rename their own folder — tracked separately.) Also widened the help command column for the longer verb names, and fixed one sed-casualty where a broad '.claudebox'→'.box' pass had turned the README's legacy user.claudebox tag into user.box.
2026-07-14 18:01:34 +00:00
`.box/` folder (older repos may use `.claudebox/`), read it as your setup runbook — how to install
feat: codex and grok templates — the mechanic's second and third tenants Two coding-CLI templates mirroring claude's shape: a box.env + verbatim cloud-init, inheriting the box-net placement contract structurally, no new design. - codex: OpenAI Codex CLI via 'npm i -g @openai/codex' (the SCOPED package; needs Node 22), symlinked onto the non-interactive exec PATH via 'npm prefix -g' — the same PATH fix the claude template needed. - grok: xAI Grok Build via the official 'curl x.ai/cli/install.sh', run AS the grok user (the installer drops into $HOME); the binary is found and symlinked to /usr/local/bin. Install commands verified upstream at implementation time, per the issue's rule (npmjs.com/package/@openai/codex, x.ai/cli). Each gets an AGENTS.md-style context file telling the agent it lives in a disposable, isolated, creds-free box. Drill: templates listing now expects four; a compact per-template smoke (mint, '<cli> --version' via box exec, remove) validates each payload installs and lands on the exec PATH — the generic mechanic is already proven by blank+claude and not repeated. Closes #54
2026-07-14 15:59:39 +00:00
dependencies, start services, template environment files, seed data, and
smoke-test — and follow it. It is documentation for you, not a script the
host runs.
package_update: true
packages:
- git
- gh
- curl
- ca-certificates
- gnupg
- ripgrep
- jq
- tmux
- age
- unzip
- build-essential
runcmd:
- curl -fsSL https://get.docker.com | sh
- usermod -aG docker grok
fix(grok): read the actual installer instead of guessing — the binary is 'grok' Fetched https://x.ai/cli/install.sh and read it, rather than inferring the layout from docs. Three facts, every one of which the template had wrong: · the CLI installs as 'grok' (with an 'agent' alias) — NOT 'grok-build'. So the drill was checking a command that never existed. · BIN_DIR defaults to $HOME/.grok/bin, and what lands there is a SYMLINK into the versioned download dir — which is exactly why the template's 'find -type f' found nothing. · GROK_BIN_DIR can override the directory. The install was almost certainly succeeding the whole time; the template was hunting for the wrong name, as the wrong file type, in the wrong place. Now it links the known path onto the system PATH, asserts 'grok --version' answers, and dumps what the installer actually left if the upstream layout ever moves. Also corrected: the drill's version check (grok, not grok-build), the agent briefing ('grok login'), the template description, and the README row. The lesson is the repo's oldest one — read the thing, don't reason about it.
2026-07-14 20:04:10 +00:00
# The OFFICIAL installer, read at https://x.ai/cli/install.sh rather than
# guessed at. What it actually does:
# · installs the CLI as `grok` (with an `agent` alias) — NOT `grok-build`
# · BIN_DIR defaults to $HOME/.grok/bin, and what it puts there is a
# SYMLINK into its versioned download dir (so `find -type f` misses it)
# · GROK_BIN_DIR overrides that directory
fix: run 17's four real findings — migrate retire, expose proxy, wait_box, grok PATH The first drill run where every failure was the RELEASE CODE, not the environment. 71 passed, 5 failed; all five traced to four bugs: 1. migrate-host --retire-legacy could NEVER succeed. Re-homing ADDS user.box=1 but never removed user.claudebox=1, and legacy_boxes() counted the old tag — so retire saw its own freshly-migrated box as un-migrated and refused forever ('legacy boxes still exist: legacybox'), leaving claudenet + claude-dev behind. Now: a verified re-home drops the legacy tag LAST (after the move is proven, so a failure anywhere above still leaves the box valid under one tag or the other), and legacy_boxes() ignores boxes already carrying user.box=1. 2. box expose died with a bare 'could not add the proxy device' — it swallowed incus's reason, exactly the sin this repo keeps punishing. Now it prints incus's error. And the mechanism is corrected: a VM's proxy needs NAT mode, which requires a static NIC address, so expose pins the box's current lease first (which also fixes the restart caveat — the exposure no longer points at a lease the box may lose). 3. wait_box's 2-minute window was too short: the legacy box was declared dead and then every migration check against it passed. 4 minutes. 4. The grok template hunted for a regular file named exactly 'grok-build' under /home/grok and found nothing — an installer's drop may be a SYMLINK, and its binary name is upstream's to choose. Now it tries the plausible names and paths, falls back to any executable grok*, links both names, and SAYS what it found — or dumps what the installer actually left when it finds nothing. The drill likewise dumps the on-disk evidence and the cloud-init log on a --version failure instead of discarding the box.
2026-07-14 19:56:17 +00:00
#
fix(grok): read the actual installer instead of guessing — the binary is 'grok' Fetched https://x.ai/cli/install.sh and read it, rather than inferring the layout from docs. Three facts, every one of which the template had wrong: · the CLI installs as 'grok' (with an 'agent' alias) — NOT 'grok-build'. So the drill was checking a command that never existed. · BIN_DIR defaults to $HOME/.grok/bin, and what lands there is a SYMLINK into the versioned download dir — which is exactly why the template's 'find -type f' found nothing. · GROK_BIN_DIR can override the directory. The install was almost certainly succeeding the whole time; the template was hunting for the wrong name, as the wrong file type, in the wrong place. Now it links the known path onto the system PATH, asserts 'grok --version' answers, and dumps what the installer actually left if the upstream layout ever moves. Also corrected: the drill's version check (grok, not grok-build), the agent briefing ('grok login'), the template description, and the README row. The lesson is the repo's oldest one — read the thing, don't reason about it.
2026-07-14 20:04:10 +00:00
# Run it AS grok, not root: the binary symlink points into the invoking
# user's download dir, and root's home is 0700 — a symlink into it would be
# unreadable to the grok user, giving a CLI that exists and cannot run.
- sudo -u grok bash -lc 'curl -fsSL https://x.ai/cli/install.sh | bash'
# 'box exec <b> -- grok …' is a NON-interactive shell: it reads no rc files,
# so ~/.grok/bin is never on its PATH. Symlink onto the system PATH — the
# same fix the claude template needed (#15). Assert the result: a CLI that
# silently is not on PATH is what cost the last drill run.
feat: codex and grok templates — the mechanic's second and third tenants Two coding-CLI templates mirroring claude's shape: a box.env + verbatim cloud-init, inheriting the box-net placement contract structurally, no new design. - codex: OpenAI Codex CLI via 'npm i -g @openai/codex' (the SCOPED package; needs Node 22), symlinked onto the non-interactive exec PATH via 'npm prefix -g' — the same PATH fix the claude template needed. - grok: xAI Grok Build via the official 'curl x.ai/cli/install.sh', run AS the grok user (the installer drops into $HOME); the binary is found and symlinked to /usr/local/bin. Install commands verified upstream at implementation time, per the issue's rule (npmjs.com/package/@openai/codex, x.ai/cli). Each gets an AGENTS.md-style context file telling the agent it lives in a disposable, isolated, creds-free box. Drill: templates listing now expects four; a compact per-template smoke (mint, '<cli> --version' via box exec, remove) validates each payload installs and lands on the exec PATH — the generic mechanic is already proven by blank+claude and not repeated. Closes #54
2026-07-14 15:59:39 +00:00
- |
fix(grok): read the actual installer instead of guessing — the binary is 'grok' Fetched https://x.ai/cli/install.sh and read it, rather than inferring the layout from docs. Three facts, every one of which the template had wrong: · the CLI installs as 'grok' (with an 'agent' alias) — NOT 'grok-build'. So the drill was checking a command that never existed. · BIN_DIR defaults to $HOME/.grok/bin, and what lands there is a SYMLINK into the versioned download dir — which is exactly why the template's 'find -type f' found nothing. · GROK_BIN_DIR can override the directory. The install was almost certainly succeeding the whole time; the template was hunting for the wrong name, as the wrong file type, in the wrong place. Now it links the known path onto the system PATH, asserts 'grok --version' answers, and dumps what the installer actually left if the upstream layout ever moves. Also corrected: the drill's version check (grok, not grok-build), the agent briefing ('grok login'), the template description, and the README row. The lesson is the repo's oldest one — read the thing, don't reason about it.
2026-07-14 20:04:10 +00:00
if [ -e /home/grok/.grok/bin/grok ]; then
ln -sf /home/grok/.grok/bin/grok /usr/local/bin/grok
echo "grok: linked /usr/local/bin/grok -> /home/grok/.grok/bin/grok"
/usr/local/bin/grok --version >/dev/null 2>&1 \
&& echo "grok: 'grok --version' answers from the system PATH" \
|| echo "grok: WARNING - linked, but 'grok --version' does not answer" >&2
fix: run 17's four real findings — migrate retire, expose proxy, wait_box, grok PATH The first drill run where every failure was the RELEASE CODE, not the environment. 71 passed, 5 failed; all five traced to four bugs: 1. migrate-host --retire-legacy could NEVER succeed. Re-homing ADDS user.box=1 but never removed user.claudebox=1, and legacy_boxes() counted the old tag — so retire saw its own freshly-migrated box as un-migrated and refused forever ('legacy boxes still exist: legacybox'), leaving claudenet + claude-dev behind. Now: a verified re-home drops the legacy tag LAST (after the move is proven, so a failure anywhere above still leaves the box valid under one tag or the other), and legacy_boxes() ignores boxes already carrying user.box=1. 2. box expose died with a bare 'could not add the proxy device' — it swallowed incus's reason, exactly the sin this repo keeps punishing. Now it prints incus's error. And the mechanism is corrected: a VM's proxy needs NAT mode, which requires a static NIC address, so expose pins the box's current lease first (which also fixes the restart caveat — the exposure no longer points at a lease the box may lose). 3. wait_box's 2-minute window was too short: the legacy box was declared dead and then every migration check against it passed. 4 minutes. 4. The grok template hunted for a regular file named exactly 'grok-build' under /home/grok and found nothing — an installer's drop may be a SYMLINK, and its binary name is upstream's to choose. Now it tries the plausible names and paths, falls back to any executable grok*, links both names, and SAYS what it found — or dumps what the installer actually left when it finds nothing. The drill likewise dumps the on-disk evidence and the cloud-init log on a --version failure instead of discarding the box.
2026-07-14 19:56:17 +00:00
else
fix(grok): read the actual installer instead of guessing — the binary is 'grok' Fetched https://x.ai/cli/install.sh and read it, rather than inferring the layout from docs. Three facts, every one of which the template had wrong: · the CLI installs as 'grok' (with an 'agent' alias) — NOT 'grok-build'. So the drill was checking a command that never existed. · BIN_DIR defaults to $HOME/.grok/bin, and what lands there is a SYMLINK into the versioned download dir — which is exactly why the template's 'find -type f' found nothing. · GROK_BIN_DIR can override the directory. The install was almost certainly succeeding the whole time; the template was hunting for the wrong name, as the wrong file type, in the wrong place. Now it links the known path onto the system PATH, asserts 'grok --version' answers, and dumps what the installer actually left if the upstream layout ever moves. Also corrected: the drill's version check (grok, not grok-build), the agent briefing ('grok login'), the template description, and the README row. The lesson is the repo's oldest one — read the thing, don't reason about it.
2026-07-14 20:04:10 +00:00
echo "grok: installer produced no ~/.grok/bin/grok - upstream layout changed?" >&2
fix: run 17's four real findings — migrate retire, expose proxy, wait_box, grok PATH The first drill run where every failure was the RELEASE CODE, not the environment. 71 passed, 5 failed; all five traced to four bugs: 1. migrate-host --retire-legacy could NEVER succeed. Re-homing ADDS user.box=1 but never removed user.claudebox=1, and legacy_boxes() counted the old tag — so retire saw its own freshly-migrated box as un-migrated and refused forever ('legacy boxes still exist: legacybox'), leaving claudenet + claude-dev behind. Now: a verified re-home drops the legacy tag LAST (after the move is proven, so a failure anywhere above still leaves the box valid under one tag or the other), and legacy_boxes() ignores boxes already carrying user.box=1. 2. box expose died with a bare 'could not add the proxy device' — it swallowed incus's reason, exactly the sin this repo keeps punishing. Now it prints incus's error. And the mechanism is corrected: a VM's proxy needs NAT mode, which requires a static NIC address, so expose pins the box's current lease first (which also fixes the restart caveat — the exposure no longer points at a lease the box may lose). 3. wait_box's 2-minute window was too short: the legacy box was declared dead and then every migration check against it passed. 4 minutes. 4. The grok template hunted for a regular file named exactly 'grok-build' under /home/grok and found nothing — an installer's drop may be a SYMLINK, and its binary name is upstream's to choose. Now it tries the plausible names and paths, falls back to any executable grok*, links both names, and SAYS what it found — or dumps what the installer actually left when it finds nothing. The drill likewise dumps the on-disk evidence and the cloud-init log on a --version failure instead of discarding the box.
2026-07-14 19:56:17 +00:00
find /home/grok -maxdepth 4 \( -type f -o -type l \) -perm -u+x 2>/dev/null | head -20 >&2
fi
fix(grok): read the actual installer instead of guessing — the binary is 'grok' Fetched https://x.ai/cli/install.sh and read it, rather than inferring the layout from docs. Three facts, every one of which the template had wrong: · the CLI installs as 'grok' (with an 'agent' alias) — NOT 'grok-build'. So the drill was checking a command that never existed. · BIN_DIR defaults to $HOME/.grok/bin, and what lands there is a SYMLINK into the versioned download dir — which is exactly why the template's 'find -type f' found nothing. · GROK_BIN_DIR can override the directory. The install was almost certainly succeeding the whole time; the template was hunting for the wrong name, as the wrong file type, in the wrong place. Now it links the known path onto the system PATH, asserts 'grok --version' answers, and dumps what the installer actually left if the upstream layout ever moves. Also corrected: the drill's version check (grok, not grok-build), the agent briefing ('grok login'), the template description, and the README row. The lesson is the repo's oldest one — read the thing, don't reason about it.
2026-07-14 20:04:10 +00:00
- echo 'export PATH="$HOME/.grok/bin:$PATH"' >> /home/grok/.bashrc
Reference in a new issue Copy permalink