Save the Exit Code Before the Smoke Host Dies

You open the team wiki on Monday and find a Friday note that says the agent patch passed on the free box. The host link no longer resolves, the shared model thread has already rotated away, and the pull request still looks finished. You cannot recover the exact command, the checked diff, or the exit code from anyone who was online. That missing proof is the failure this playbook is written to prevent before the next reclaim.

Generated drafts and clickable pages now land in review faster than most teams can archive what actually ran. A clickable review page is not evidence, and a vanished smoke host is not a failed test you can still debug. Your team needs a capture step that finishes before the box is reclaimed and before the model session scrolls out of reach. The sections below name the roles, the handoff comment, and a one-page run you can paste into the wiki today.

What disappears if you wait

Ephemeral check hosts stay useful because they are cheap and disposable, which is also why they make poor long-term archives. A free server option may reboot, expire, or be reused by the next person on the shared rota. A free model session can drop the earlier turns that explained why a particular flag was chosen. If you wait until the Monday standup to copy those logs, the only remaining record is a vague sentence.

Treat the box as a workbench, not as the system of record your reviewer will trust next week. The repository, or the wiki page sitting next to it, should hold the rev, the command, the exit code, and a bounded log. Anything you cannot copy in one pass should be marked missing, rather than implied by a green line in chat. You are not trying to preserve the whole machine image, because that goal is too large for a Friday check.

You are trying to preserve enough for a teammate to rerun the same check or to reject the claim cleanly. That narrower target keeps the run short enough to finish before someone else needs the same host. A later reader should see a file, not a story about a file that used to exist on a host. If the file is absent, the claim is incomplete, even when the chat tone sounded confident.

Roles and the handoff

Assign three names on the wiki page before the first command runs, even when the team is small. The runner executes the check and refuses to close the host until the proof file exists in the branch. The reviewer accepts or rejects that proof file, and does not accept a chat summary in its place. The reclaimer is the only person who may destroy or reuse the box, and only after the reviewer marks the proof complete.

Handoff is a single written comment, not a meeting you schedule after the host is already gone. The runner pastes the proof path, the git revision, and the exit code, then tags the reviewer by name. The reviewer replies with proof accepted, or with a short list of the fields that are still missing. The reclaimer waits for that reply, then notes the reclaim time so the next runner does not inherit a dirty host.

If one person must wear two of these hats, they still write both role names on the page. The second action should look like a separate step, even when the same human performs it later. Skipping that split is how a tired runner reclaims the box and then discovers the log was never copied. Write the names beside the date, so the next Monday reader knows who still owes a reply.

One-page run you can paste

Paste the following eight steps into the wiki as the only happy path for this class of check. Do not add side notes that contradict the order, because the order is what keeps the proof ahead of reclaim. Each step should leave a visible artifact, so a later reader can see where the run stopped. Keep the page short enough that a new runner can follow it without asking for a walkthrough.

1. Create a working branch and record the output of git rev-parse HEAD in the proof note before you start the check.
2. Write the exact command you will run, including the working directory, and do not paraphrase that command later in chat.
3. Run the check on the ephemeral host, and tee a bounded log into a file under the proof directory.
4. Record the exit code from the shell itself, not from a sentence the model composed after the command finished.
5. Copy the proof note and the bounded log into the branch, then commit both with the revision in the message.
6. Post the handoff comment with the proof path, the revision, and the exit code, and tag the named reviewer.
7. Wait for proof accepted, or for a missing-field list, before anyone reclaims or reimages the shared host.
8. If the host dies early, mark the proof incomplete and schedule a rerun instead of reconstructing the log from memory.

A handoff comment can stay this plain, and you should resist adding a narrative about how the run felt. Put the four fields in a fenced block so the reviewer can scan them without opening the whole log. Leave the status line as awaiting proof accepted until the named reviewer writes that phrase back. Do not attach screenshots of a dead host, because a screenshot cannot be rerun by the next person.

proof: proof/evidence.md
rev: <git rev>
exit: <integer>
reviewer: <name>
status: awaiting proof accepted

Example snapshot script

The script below is a local template you can adapt, not a report of a run on your infrastructure. You should execute it in a scratch repository and adjust the log path before you trust the output. It refuses to write a proof note when the revision, the command, or the exit code is missing. Treat the file it writes as an example capture, and review the log tail before you commit it.

#!/usr/bin/env bash
set -euo pipefail

REV="${1:-}"
CMD="${2:-}"
CODE="${3:-}"
LOG="${4:-proof/check.log}"
OUT="proof/evidence.md"

if [[ -z "$REV" || -z "$CMD" || -z "$CODE" ]]; then
  echo "usage: snapshot.sh <git-rev> <command> <exit-code> [log]" >&2
  exit 2
fi

mkdir -p proof
{
  echo "# Evidence note"
  echo
  echo "- Rev: ${REV}"
  echo "- Command: ${CMD}"
  echo "- Exit code: ${CODE}"
  echo "- Captured: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
  echo
  echo "## Bounded log"
  echo
  if [[ -f "$LOG" ]]; then
    tail -n 200 "$LOG"
  else
    echo "LOG MISSING: ${LOG}"
  fi
} > "$OUT"

echo "wrote ${OUT}"

Run the check first, then pass that shell exit code as the third argument, because a later command will replace it. If you pipe through tee, read the check status from PIPESTATUS rather than from the exit code of tee. The commands below are an unexecuted example, so replace the test path with the check your team actually trusts. Do not commit this snippet as proof that a suite passed, because it only shows how to record a status.

mkdir -p proof
set +e
pytest -q tests/agent_smoke | tee proof/check.log
code=${PIPESTATUS[0]}
set -e
bash snapshot.sh "$(git rev-parse HEAD)" "pytest -q tests/agent_smoke" "$code" proof/check.log
test -f proof/evidence.md

A reviewer can reject the note when the log section says the log is missing, or when the exit code is not an integer. You can add a small CI check that fails the branch if the evidence file is absent on agent-path changes. That check does not prove the model was correct, but it does prove someone captured a result before review. Keep the template in the wiki next to the eight steps so the runner does not invent a different format.

What to keep and what to leave

Use the table as a capture policy for this run, and review it again when your data rules change. Keep the revision, the exact command, the exit code, and a short log tail in git or in the wiki. Leave the full disk image and the vendor cache on the box until the reclaimer is allowed to wipe them. Never commit secrets, tokens, or live credentials, and wipe them from the host before the next runner arrives.

Artifact	Keep in git or the wiki	Leave on the box
Git revision and exact command	Yes	No
Exit code and bounded log tail	Yes	No
Secrets, tokens, and live credentials	No	No, wipe them
Full disk image or vendor cache	No	Yes, until reclaim
Model chat that explains a flag	Short quote tied to the rev	Rest may expire

If a command printed a secret into the log, rotate that secret and do not commit the raw file. The bounded tail is only a convenience, so you still scan it by eye before the commit lands. A short quote from the model chat may explain a flag, but it must sit next to the revision it refers to. The rest of the chat may expire, which is acceptable when the command and the exit code already live in git.

Where the free lane fits

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode belongs in this run only as the lane you might use for the draft and for the smoke host. The operator describes free model access and a free server option that can hold this kind of disposable check. This article does not quote a token quota, a hardware size, a time limit, or a promise that the offer stays fixed. Those details can change, so you should read the current project page before you plan capacity around them.

Use the free model to draft the command list, then have the runner paste the exact command into the proof note. Use the free server as the workbench in the third step, and still copy the proof off the box in the fifth step. If either free option is unavailable that day, the same run works on any scratch host you already control. The playbook remains useful when the product mention is removed, because the proof still has to live in your repository.

Paste these eight steps into your checks page, then confirm the current MonkeyCode free-lane terms before you assign the host. Do that check on the project page the same day, because a note from last month is not a capacity plan. If the page lists different limits than you expected, shrink the check until it fits, or move it to a host you control.

Limitations and who should skip this

This run does not replace production change control, and it does not prove that a model answer is accurate. A captured exit code can still belong to the wrong test, which is a separate oracle problem you should track elsewhere. The sample script does not redact secrets for you, so a careless log can still leak into the repository. You should scan every tail yourself, or with a secret scanner you already trust, before the commit is pushed.

Skip this approach when the check handles regulated data, or when policy requires a retained forensic image of the host. Skip it when your rules forbid pasting command text into a wiki, even if the command itself looks harmless. Skip it when nobody can serve as reviewer, because an unread proof file is only another note in the archive. Short-lived boxes are also a poor fit for long jobs that cannot finish before the reclaimer needs the machine back.

Start with one agent path and one scratch host, and keep the proof file boring enough that a reviewer can read it quickly. After two weeks, look at which fields reviewers actually reject, and tighten the template instead of adding more roles. The habit you want is simple: no reclaim until the revision, the command, and the exit code are already in git. That habit survives tool changes, which is why the wiki page should describe the proof rather than a particular vendor screen.