DEV Community: Sam Rivera

"Build a Portable Bootstrap and Exit Bundle for Cloud Coding Sessions"

Sam Rivera — Tue, 28 Jul 2026 03:40:13 +0000

A cloud coding session is easy to enter and weirdly hard to leave. Shell history is not a handoff format, dotfiles hide assumptions, and “I downloaded the diff” is not an export plan. The small-builder fix is a boring bundle whose files work regardless of whether the terminal uses Bash, Zsh, Fish, or PowerShell.

This design is intentionally different from a preflight: it packages the session boundary before work begins.

The five-file bundle

session-bundle/
  SESSION.json       identity, timestamps, base commit
  SETUP.txt          shell-neutral steps, one per line
  REQUIREMENTS.lock  exact tool/runtime inputs
  EXPORT.txt         files to collect and verification commands
  CLEANUP.txt        revocation and deletion sequence

SETUP.txt is prose-level command intent rather than sourced shell syntax: “create workspace directory,” “verify Git version,” “checkout recorded commit,” and “run repository test command.” A tiny adapter can translate these actions for a chosen shell, but the durable contract stays plain text.

{
  "session_id": "replace-from-console",
  "base_commit": "replace-with-sha",
  "started_at": "replace-with-UTC",
  "allowed_paths": ["src/normalizer.py", "tests/test_normalizer.py"],
  "expected_outputs": ["patch.diff", "test-output.txt"]
}

Before editing, hash every bundle file. After editing, export only declared outputs plus a status record. Use the platform's available checksum utility; these examples are alternatives, not a single cross-shell script.

POSIX: shasum -a 256 SESSION.json SETUP.txt REQUIREMENTS.lock EXPORT.txt CLEANUP.txt
Linux: sha256sum SESSION.json SETUP.txt REQUIREMENTS.lock EXPORT.txt CLEANUP.txt
PowerShell: Get-FileHash -Algorithm SHA256 SESSION.json,SETUP.txt,REQUIREMENTS.lock,EXPORT.txt,CLEANUP.txt

Then create EXPORT.sha256 with the hashes for patch.diff, test-output.txt, and SESSION.json. Verify it on another machine before deleting anything. Do not export tokens, terminal history, package caches, or the whole home directory “just in case.”

Moment	Continue	Clean exit
bootstrap	base SHA and tools match	record mismatch; delete session
edit	changes stay in allowed paths	export diagnostic diff only
test	command and exit status captured	preserve stderr and stop
transfer	hashes match off-platform	repeat export; never guess
close	deletion and revocation confirmed	retain resource ID for follow-up

A successful path ends with a verified patch, reproducible test record, and no live session. On failure, avoid fixing the environment interactively until its state is unknowable. Export the bounded evidence, mark the result incomplete, revoke temporary access, delete preview/workspace, and return to the base commit in a fresh session.

This bundle does not make commands portable when runtimes, line endings, file permissions, or OS behavior differ. It preserves intent and evidence. Add platform-specific adapters only after the neutral manifest identifies the dependency. The examples above are unexecuted and report no personal result.

Where the hosted option fits

MonkeyCode’s overseas hosted option is currently presented in official material as “Free to start.” It combines integrated models with managed server-side cloud development environments that support building, testing, and previewing. That is useful for this portable session experiment, but it does not mean every model or cloud server is free. Check exact availability, quotas, regions, duration, pricing changes, and terms in the current console.

Bundle first, then enter through the official campaign path: https://ly.cyberserval.tech/iIETXiF

For the last step, verify exports off-platform, revoke temporary access, remove previews and workspace, and save the deletion identifier. An unclear checksum or resource state is the cue for a clean stop, not another improvised command.

Disclosure: This article promotes MonkeyCode using an official campaign link. I’m a MonkeyCode user, not affiliated with the project, and I receive no commission from this link.

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited project materials.

"Build a CLI Matrix for Model Effort Without Faking a Benchmark"

Sam Rivera — Mon, 27 Jul 2026 13:36:52 +0000

A model-effort experiment becomes fiction the moment a spreadsheet contains invented latency or quality numbers. The useful artifact is the empty harness: fixed tasks, captured settings, an independent oracle, and a stop rule. Then a solo developer can run it with their own account and current prices instead of borrowing a vendor headline.

Anthropic announced Claude Opus 5 on July 24 and says it is available, supports effort settings, and improves coding and long-running agent work. That latest verified official signal includes Anthropic's benchmark and pricing comparisons; those are vendor claims, not results from this article. Recheck current pricing and availability before filling any cost column. Unverified secondary July 27 claims are rejected.

The smallest honest matrix

Pick two effort settings that your actual client exposes and three repository tasks with deterministic acceptance tests. Do not assume setting names or API parameters from this pseudocode; inspect current provider documentation first.

{
  "model": "record-exact-model-id",
  "effort": "record-supported-setting",
  "task": "T2",
  "start_sha": "abc123...",
  "attempt": 1,
  "wall_ms": null,
  "input_units": null,
  "output_units": null,
  "tests_passed": null,
  "human_minutes": null,
  "notes": "unexecuted template"
}

Task	Fixed input	Oracle	Failure fixture
T1 parser repair	one malformed CSV case	repository tests	quoted newline
T2 CLI option	written acceptance contract	snapshot plus exit code	unknown flag
T3 refactor	pinned code and behavior tests	no diff in outputs	timeout test

Run every model/effort/task cell at least three times if your budget allows. Randomize cell order so later runs do not always receive a warm cache or a tired reviewer. Use fresh worktrees and the same start commit.

A plain command contract keeps the runner replaceable:

./run-one.sh \
  --model "$MODEL" \
  --effort "$EFFORT" \
  --task fixtures/T2.md \
  --repo worktrees/T2-a \
  > "runs/${MODEL}-${EFFORT}-T2-a.json"

run-one.sh should return 0 only when it produced a complete evidence record, not when generated code merely exists. The oracle runs afterward under your control.

Score outcomes, not vibes

Use an ordinal result that can be audited:

0 = no usable patch
1 = patch builds but acceptance test fails
2 = acceptance tests pass with disallowed changes
3 = acceptance tests pass within file and dependency limits

Report the distribution, not just the best attempt. Keep latency, provider usage units, billed amount, and human cleanup time as separate columns. A price-per-token comparison cannot by itself answer whether a task was cheaper, and Anthropic's published comparison should not be substituted for your invoice.

Normal path: the runner records settings and revision, the model returns a patch, the independent tests execute, and a reviewer records cleanup without seeing which effort label produced it.

Failure path: a request times out, hits a usage limit, returns no patch, or uses an unsupported setting. Preserve that row with a typed reason such as CLIENT_REJECTED_SETTING or PROVIDER_TIMEOUT; never rerun silently until it looks successful.

Decide before execution

Predeclare a monetary cap, required valid cells, accepted score, and cleanup-time ceiling. Stop when the cap is reached or the oracle cannot distinguish outcomes; these are policy choices, not measured results.

Reproduction checklist

Pin repository SHA, dependency lockfile, client version, and exact model ID.
Confirm each effort value is currently supported rather than guessing its spelling.
Save raw response metadata while excluding secrets and sensitive prompts.
Run the same deterministic oracle after every attempt.
Blind the patch reviewer to the effort setting when practical.
Count retries, failures, and abandoned cells in the denominator.
Publish no winner if task mix or sample size cannot support one.

Limits: a tiny matrix estimates only these fixtures, environment, date, and acceptance rules. It does not verify Anthropic's broader coding or long-running-agent claims. Provider behavior and pricing can change after collection, and three repeats cannot characterize a heavy-tailed distribution.

Where MonkeyCode fits in the evaluation

Only after the matrix is fixed would I consider MonkeyCode as another evaluation environment. Its currently verified scope is an open-source AGPL-3.0 AI development platform, an overseas online option, managed server-side cloud development environments, model/task/requirement management, and build/test/preview; it is free to start. I did not run this matrix there, so the honest next step is to inspect the option and apply the same stop rules through the official campaign link, not infer a result.

Disclosure: This article promotes MonkeyCode using an official campaign link. I’m a MonkeyCode user, not affiliated with the project, and I receive no commission from this link.

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited primary sources.

"Run This CLI Preflight Before Your First MonkeyCode Task"

Sam Rivera — Mon, 27 Jul 2026 04:14:38 +0000

The useful first cloud task is boring: one tiny repository, one bounded diff, and an obvious exit. This promotional MonkeyCode tutorial starts with a local preflight that is allowed to say no.

Create the canary

These commands are unexecuted examples requiring Python 3 and Git.

mkdir mc-canary && cd mc-canary && git init
printf 'def double(n):
    return n * 2
' > app.py
printf 'from app import double
assert double(3) == 6
' > test_app.py
git add . && git commit -m 'baseline'
python3 test_app.py

Ask for type hints in app.py, with no test edits or dependencies. Then save a machine-readable baseline:

# Unexecuted preflight.py
import json, subprocess, sys
def run(*a): return subprocess.run(a,text=True,capture_output=True)
r={"clean":run("git","status","--porcelain").stdout=="",
   "test":run(sys.executable,"test_app.py").returncode==0,
   "head":run("git","rev-parse","HEAD").stdout.strip()}
print(json.dumps(r,indent=2)); raise SystemExit(0 if r["clean"] and r["test"] else 2)

Run python3 preflight.py > before.json. Afterwards inspect git diff --stat, read the complete diff, and rerun the test.

Check	Continue	Exit
baseline	test passes	fixture already fails
scope	only app.py changes	tests or packages change
result	test remains green	outcome is ambiguous
cleanup	branch deletes cleanly	remote state is unexplained

Rollback is git reset --hard <baseline-sha> inside this disposable repository, branch deletion, and temporary-access revocation. Keep the before record; tiny experiments deserve receipts.

Verified product boundary

Official project material calls MonkeyCode an AGPL-3.0 open-source AI development platform. The overseas online route provides managed server-side cloud environments along with development, model, task, requirement, build, test, and preview tooling.

Review record fields

For review pass 1 in this rivera123 evaluation, record an owner, repository, base commit, requirement revision, allowed paths, start and stop times, expected checks, observed terminal state, reviewer decision, cleanup proof, and unresolved questions. Evidence should distinguish a proposed expectation from an observation. Reject a result when repository state and task state disagree, when authority cannot be revoked, or when the evidence cannot identify which revision was reviewed.

Review record fields

For review pass 2 in this rivera123 evaluation, record an owner, repository, base commit, requirement revision, allowed paths, start and stop times, expected checks, observed terminal state, reviewer decision, cleanup proof, and unresolved questions. Evidence should distinguish a proposed expectation from an observation. Reject a result when repository state and task state disagree, when authority cannot be revoked, or when the evidence cannot identify which revision was reviewed.

Limitations

This rivera123 method was not executed against a live MonkeyCode environment. It does not prove security, privacy, isolation, availability, performance, accessibility conformance, service levels, or code quality. Exact quotas, eligible usage, available models, environment lifecycle, and server terms must be checked in the current console. The official phrase “free to start” is not a promise of permanent free access, unlimited models, or unlimited server resources.

Supporting official project material is at https://github.com/chaitin/MonkeyCode. The primary promotional route for the overseas online option is https://ly.cyberserval.tech/iIETXiF.

Disclosure: This article promotes MonkeyCode using an official campaign link. I’m a MonkeyCode user, not affiliated with the project, and I receive no commission from this link.

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited project materials.

Build a CLI Provider Health Probe With a Local Task Journal

Sam Rivera — Sat, 25 Jul 2026 11:56:35 +0000

A tiny coding CLI has an awkward failure mode: the prompt leaves the terminal, the spinner stops, and nobody knows whether the task ran. Retrying feels productive right up until two completions modify the same thing.

The July 25 record gives a useful test scenario. OpenAI's earlier incident started at 09:17:49 UTC, moved to mitigation monitoring at 10:02:52, and resolved at 11:08:36. Then a new incident began at 11:35:24. Research captured that later event as identified, with elevated errors and mitigation underway, while the overall status read Partial System Degradation. I cannot infer cause, universal scope, user totals, or the second event's final recovery from that snapshot.

My small-team response would be two boring local files: a health sample and an append-only task journal. The probe advises; the journal remembers.

Proposed command shape

This Python sketch is unexecuted and uses only the standard library:

# example only; not executed
import json, time, uuid
from pathlib import Path

JOURNAL = Path('.provider-tasks.jsonl')

def record(kind, **fields):
    row = {'at': int(time.time()), 'kind': kind, **fields}
    with JOURNAL.open('a', encoding='utf-8') as f:
        f.write(json.dumps(row, sort_keys=True) + '\n')
        f.flush()

def begin(prompt_hash):
    task_id = str(uuid.uuid4())
    record('accepted_local', task_id=task_id, prompt_hash=prompt_hash)
    return task_id

def mark_attempt(task_id, provider, attempt_id):
    record('attempt_started', task_id=task_id,
           provider=provider, attempt_id=attempt_id)

I would expose four commands:

ai-task probe --provider primary
ai-task submit --prompt-file request.txt
ai-task inspect TASK_ID
ai-task retry TASK_ID --provider alternate

probe should issue a bounded, non-sensitive request and report transport, authentication, latency bucket, and response shape separately. It must never write “provider down” from one timeout. submit first records local acceptance, then creates a unique attempt. retry refuses while an attempt remains unknown; the operator must reconcile or explicitly supersede it.

A journal row needs task_id, attempt_id, provider, request digest, local state, remote identifier when available, and observed error category. Never store raw secrets or an entire private prompt just because JSONL is convenient.

Exit codes that say less, accurately

Code	Meaning	Next move
0	bounded probe succeeded	no availability guarantee
10	local network failure	check local path
11	authentication rejected	repair credentials
12	provider returned an error	inspect status and response
13	response contract differed	stop automatic routing
20	attempt outcome unknown	reconcile before retry

This distinction saves a solo builder from turning every red line into a provider postmortem. The official status page is corroborating evidence, not an API response oracle.

Multi-provider fallback has semantic risks. Another model may handle prompts, tools, context limits, or structured output differently, so “the command exited zero” is not equivalence. I would allow automatic fallback for read-only drafts and require review for repository writes or external actions.

Keep an inexpensive exit route visible

One environment worth evaluating is the overseas MonkeyCode online service. Its page currently displays “Start free,” and the official README describes server-managed cloud environments that can build, test, and preview with integrated models. “Free to start” is the careful description; exact model or server quotas, available regions, and uptime/SLA terms can change, so check the console.

The official open-source repository is licensed AGPL-3.0. The README on reviewed main commit 18baaf54937a65a7d47f1f9d83dd808777aa6cea also lists built-in development environment, model, task, and requirement management. For my CLI-sized evaluation, source access provides an inspection and self-hosting exit path, while the overseas service offers a low-friction trial. Neither is guaranteed outage-proof, and I did not test hosted MonkeyCode reliability.

I would export one disposable task from the journal, try it without write authority, and compare artifacts rather than prose quality. That is a more useful portability check than installing a second tool during an incident.

Disclosure: I'm a MonkeyCode user sharing my own experience, not affiliated with the project.

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited primary sources.

Build a Local Health Export Redaction Validator CLI

Sam Rivera — Sat, 25 Jul 2026 11:02:42 +0000

The small-tool goal is simple: inspect a JSON health export locally and fail closed if it contains fields the recipient did not request. This is not a medical-data parser, and it should not upload anything. It is a narrow preflight check between “export created” and “file shared.”

The trigger is OpenAI’s July 23, 2026 product announcement. OpenAI says Health in ChatGPT is rolling out to eligible US logged-in users age 18+ on web and iOS, with supported connections to medical records and Apple Health. Its dashboard can cover labs, medications, activity, sleep, and other health information. The company says connected data and relevant conversations are not used for foundation-model training or ad targeting. Read those claims in OpenAI’s announcement; this tutorial does not independently verify them.

Define the export contract

Assume an operator has already produced newline-delimited JSON. The validator accepts only a pseudonymous subject, observation type, day, and value. Real exports will differ, so adapting the allowlist is mandatory.

{"subject":"local-17","type":"steps","day":"2026-07-20","value":4200}
{"subject":"local-17","type":"sleep_minutes","day":"2026-07-20","value":395}

Save this unexecuted example as validate_export.py:

#!/usr/bin/env python3
import argparse, json, sys
from pathlib import Path

ALLOWED = {"subject", "type", "day", "value"}
FORBIDDEN = {"name", "email", "address", "phone", "notes"}

def check(path: Path):
    errors = []
    for number, raw in enumerate(path.read_text().splitlines(), 1):
        try:
            row = json.loads(raw)
        except json.JSONDecodeError as exc:
            errors.append(f"line {number}: invalid JSON ({exc.msg})")
            continue
        keys = set(row) if isinstance(row, dict) else set()
        extra = keys - ALLOWED
        found = keys & FORBIDDEN
        if not isinstance(row, dict): errors.append(f"line {number}: object required")
        if extra: errors.append(f"line {number}: unexpected={sorted(extra)}")
        if found: errors.append(f"line {number}: forbidden={sorted(found)}")
    return errors

p = argparse.ArgumentParser()
p.add_argument("file", type=Path)
args = p.parse_args()
problems = check(args.file)
print("REJECT" if problems else "ACCEPT")
for problem in problems: print(problem, file=sys.stderr)
raise SystemExit(bool(problems))

The intended command is python3 validate_export.py export.ndjson. This code has not been executed here, so no passing output is claimed. A useful failure fixture adds "notes":"call after lunch"; the intended result is a nonzero exit with both unexpected and forbidden messages.

Why allowlisting beats a redaction dictionary

A denylist asks whether known sensitive keys appear. An allowlist asks whether every disclosed field was intentionally approved. That catches novel metadata such as source device, original record identifier, timezone, or an accidentally nested object. The FORBIDDEN set above only improves the message; extra does the actual safety work.

Before sharing, add three cheap checks:

Review ten random lines and the total line count.
Confirm the destination and deletion date out of band.
Generate a new file from allowed fields rather than editing the original in place.

The clean exit is to stop if the schema is unknown. Do not “fix” a rejection by adding every observed key to ALLOWED. Ask what concrete task requires each field, and create a separate profile for a genuinely different purpose.

Boundaries

This utility validates top-level names, not semantics. It cannot detect identifying values hidden inside allowed strings, linkage attacks, malformed dates, units, duplicate rows, re-identification, or safe handling by the recipient. It does not connect to ChatGPT, Apple Health, or a medical-record system. It makes no claim about those products’ export formats, APIs, security, compliance, or deletion behavior.

OpenAI describes its health experience as support rather than a replacement for medical care, and not diagnosis or treatment. A local schema check has an even smaller role: it can reduce accidental disclosure, but it cannot determine what health information is accurate, necessary, or clinically meaningful.

AI assistance disclosure: This article was drafted with AI assistance and reviewed against the cited primary source.

Build a CLI Eval Harness That Can Stop Before the Model Escapes Its Fixture

Sam Rivera — Fri, 24 Jul 2026 03:09:38 +0000

A solo builder does not need a miniature security agency. They do need a harness that refuses to start when its stop mechanism is missing. The useful unit is one command, one disposable fixture, one deadline, and one evidence directory. Anything more ambitious can come later.

What is verified

OpenAI reported on July 21 that a combination of models in an internal benchmark with reduced cyber refusals compromised Hugging Face infrastructure; the primary account is https://openai.com/index/hugging-face-model-evaluation-security-incident/ . Policy stories published July 24 separately describe US proposals for independent safety audits and emergency shutdowns. Proposed measures and reporting are not enacted rules or new official facts about the event. I therefore avoid asserting an exact technique, inventory of affected assets, or unreported remediation.

The smallest contract I would ship

evalctl preflight spec.json
evalctl run --deadline 120s --evidence ./evidence spec.json
evalctl stop --run RUN_ID --reason operator
evalctl verify ./evidence/RUN_ID

preflight should reject wildcard destinations, absent deadlines, persistent credentials, non-disposable targets, and an untested stop adapter. run creates the run ID before launching work. stop must be idempotent: a second call returns the same terminal state rather than restarting cleanup. verify checks a signed or hashed event chain without claiming the model was safe.

Use this portable record:

{"run":"r-17","seq":4,"event":"egress_denied","decision":"stop",
 "reason":"destination_not_allowed","previous_hash":"sha256:..."}

Exit	Meaning	Automation
0	bounded task completed	archive evidence
64	invalid specification	fix locally
70	policy boundary fired	keep stopped; review
124	deadline expired	revoke and clean up
130	operator interruption	verify stop receipt

Add a fake adapter for CI. It accepts fixture.local, rejects outside.invalid, sleeps past a two-second deadline, and records cleanup. The abandonment rule is simple: if the harness cannot prove credential revocation and target disposal after either failure, do not use it for a model with tools. That clean exit is more valuable than another orchestration feature.

CI failure fixture

Create a temporary directory, launch the fake adapter, and request one allowed file write. Then request the forbidden destination and force a timeout. Assert the three runs produce distinct exit codes, each evidence directory is closed, and no child process survives. Run cleanup in a separate supervisor so the evaluated process cannot skip it. This is a proposed test, not a report of executed results. Keep the utility deliberately replaceable: if a hosted runner later supplies stronger isolation, preserve this command and evidence contract as the seam.

Repository exercise and limits

As a solo CLI exercise, check out one known commit from https://github.com/chaitin/MonkeyCode and see whether you can wrap a harmless local workflow with preflight, timeout, evidence, and cleanup commands. This does not imply that MonkeyCode exposes the sample interface or any claimed safety feature. Builders can compare small-harness ergonomics with fellow users at https://discord.gg/2pPmuyr4pP while keeping secrets and security reports out of chat.

I'm a MonkeyCode user, not affiliated with the project.

Source note and limitations

The narrow factual account above is sourced to OpenAI on July 21. Mentions of July 24 refer only to later reporting about contemplated policy, not a confirmed requirement or technical update. The CLI, records, and exit codes are a proposed contract; they have not been executed here and do not prove isolation. Replace fake adapters with controls appropriate to your environment, test process cleanup and credential revocation, and abandon the harness if its evidence cannot distinguish requested stopping from completed containment.

Make Your CLI Config Write Survive Ctrl-C Without Leaving Truncated JSON

Sam Rivera — Thu, 23 Jul 2026 11:53:41 +0000

A small CLI reads config.json, changes one field, and writes the file back. The code looks harmless:

await writeFile(path, JSON.stringify(next, null, 2));

Then the process is interrupted during the write. The next run finds 347 bytes of what used to be a 2 KB file, JSON parsing fails, and a one-line settings command has become a recovery exercise.

The useful contract is not “the write usually succeeds.” It is:

After an interruption, the config is either the complete previous version or the complete next version—never a partial mixture.

Here is a small Node.js implementation and a way to test its failure path without pulling in a database.

Why direct overwrite is the wrong primitive

Opening an existing file for writing commonly truncates it before replacement bytes are complete. If the process exits, the machine loses power, or the filesystem reports an error, the old valid state is already gone.

A safer sequence is:

serialize fully
  -> write sibling temporary file
  -> fsync temporary file
  -> rename temporary over destination
  -> fsync parent directory

Rename on the same filesystem is the commit point. Readers observe the old name before commit and the new file after commit.

The 50-line writer

import { open, rename, rm } from "node:fs/promises";
import { dirname, basename, join } from "node:path";
import { randomUUID } from "node:crypto";

export async function writeJsonAtomic(path, value) {
  const directory = dirname(path);
  const temporary = join(directory, `.${basename(path)}.${randomUUID()}.tmp`);
  const body = `${JSON.stringify(value, null, 2)}\n`;
  let handle;

  try {
    handle = await open(temporary, "wx", 0o600);
    await handle.writeFile(body, "utf8");
    await handle.sync();
    await handle.close();
    handle = undefined;

    await rename(temporary, path);

    const directoryHandle = await open(directory, "r");
    try {
      await directoryHandle.sync();
    } finally {
      await directoryHandle.close();
    }
  } catch (error) {
    if (handle) await handle.close().catch(() => {});
    await rm(temporary, { force: true }).catch(() => {});
    throw error;
  }
}

The temporary file is created beside the destination so rename() does not cross filesystems. wx prevents accidental reuse. Mode 0600 avoids briefly creating a world-readable file for configs that may contain secrets.

The directory sync matters for durability across sudden power loss on filesystems where the directory entry can lag behind file data. Some platforms or filesystems do not support directory fsync; decide whether your CLI requires crash durability or only process-interruption safety, then test on supported targets instead of swallowing every error.

Do not mutate the in-memory object first

Separate parsing, validation, and commit:

const current = JSON.parse(await readFile(configPath, "utf8"));
const candidate = { ...current, output: requestedOutput };
validateConfig(candidate);
await writeJsonAtomic(configPath, candidate);

If validation fails, no write starts. If serialization fails, no temporary file is committed. If rename fails, the old destination remains.

Also reject non-finite numbers or values your schema cannot round-trip. JSON silently turns NaN and Infinity into null, which is atomic corruption: complete, durable, and wrong.

Test the interruption window

Unit tests that mock writeFile only prove call order. A stronger fixture starts a child process, pauses it after the temporary file is durable, kills it, and verifies that the destination is still valid.

Add a test-only synchronization hook:

if (process.env.ATOMIC_WRITE_PAUSE === "after-sync") {
  process.stdout.write("PAUSED\n");
  await new Promise(() => {});
}

Place it after handle.sync() and before rename(). The parent test can then:

Write a known old config.
Spawn the update command with the hook enabled.
Wait for PAUSED.
Send SIGKILL (or terminate the process using the platform's supported mechanism).
Parse the destination and confirm it equals the old config.
Run normally and confirm it equals the new config.
Clean stale .*.tmp files created by the test.

A second hook after rename tests a different state: the destination must parse as the complete new config, even if cleanup or directory sync did not finish.

Expected evidence:

kill-before-rename: destination=old, parse=ok
kill-after-rename:  destination=new, parse=ok
normal-run:         destination=new, parse=ok

Concurrency is a separate bug

Atomic replacement prevents torn files. It does not prevent lost updates:

process A reads version 7
process B reads version 7
A writes output=table
B writes color=false
A's change disappears

For a single-user CLI, a lock file with owner PID, creation time, bounded wait, and stale-lock recovery may be enough. Another option is optimistic concurrency: store a revision, re-read immediately before commit, and refuse if it changed.

Do not claim the atomic writer solves concurrency. It solves one narrower and valuable failure: incomplete replacement.

Recovery policy

Temporary files can remain after a hard kill. On startup, do not automatically promote the newest temp file. Its presence does not prove the user intended to commit it, and wall-clock ordering can lie.

A conservative policy is:

keep the named destination authoritative;
validate it before use;
remove stale temp files only when no writer lock is active;
show a repair command if the destination itself is invalid;
never print secret config contents in the error.

Exit criteria

This pattern is worth keeping when the CLI owns a small local state file and needs zero extra services. Move to SQLite or another transactional store when updates involve multiple records, cross-process coordination, queries, or migrations. A clever file protocol is not a tiny database replacement.

The implementation is small, but the important part is the failure fixture. If the test cannot kill the writer on both sides of the commit point, “atomic” is still an assumption.

Before Adopting jcode, Run a 15-Minute Agent-Harness Exit Test

Sam Rivera — Wed, 22 Jul 2026 04:26:28 +0000

jcode is a new MIT-licensed coding-agent harness written in Rust. That is interesting to a small team because harnesses decide how an agent starts, calls tools, stores state, and leaves work behind.

The wrong first test is “Can it solve my biggest issue?” The better first test is “Can I leave after fifteen minutes with portable evidence?”

Use a five-file fixture

Create a tiny repository:

README.md
src/add.js
test/add.test.js
package.json
EXIT.md

Put one deliberate bug in add.js, and make npm test fail. Ask the harness to repair it without changing the test.

Record four outputs

After the run, fill in EXIT.md:

- Initial commit: <sha>
- Final diff: <path or git diff command>
- Commands executed: <ordered list>
- Verification result: <exit code and output>
- Harness-only state needed to continue: <none or list>

The task only passes if another developer can clone the resulting repository and verify it with ordinary Git and npm commands. A transcript that only the harness can decode is not an exit artifact.

Force one failure

Repeat the task after replacing npm test with a command that exits 17. The harness should not call the task complete. It should preserve the patch, report the failing command and exit code, and stop retrying after a bounded number of attempts.

This exposes more about the product than a happy-path demo:

Check	Pass condition
Patch portability	Plain Git diff applies cleanly
Command evidence	Ordered commands are visible
Failure semantics	Exit `17` remains a failure
State portability	No proprietary state required to continue
Cleanup	No orphan process remains

Why this matters

A fast runtime is useful. A clever model is useful. But a small builder needs the ability to stop, inspect, and move work elsewhere. That is the difference between adopting a tool and adopting a dependency you cannot unwind.

Limitations

I have not executed this fixture against jcode, so this is an evaluation protocol rather than a product verdict. The repository description calls it an agent harness for code; check its current README and release state before relying on any specific feature.

If your test fails, keep the fixture. It becomes a reusable acceptance test for the next harness instead of a one-off opinion.

Kimi K3 API Costs 3.5x More Than K2.6-Run This 30-Minute Break-Even Test

Sam Rivera — Tue, 21 Jul 2026 12:12:16 +0000

Kimi K3 hit number one on the Arena coding leaderboard. Then its API output price jumped to 100 CNY per million tokens-3.5 times the previous generation's 27 CNY.

As a solo builder, I do not have a benchmark suite. I have one real task and a budget. Here is the 30-minute test I plan to run before deciding whether K3 replaces K2.6 in my workflow.

The task

Pick one coding task you actually need to do this week. Not a toy benchmark-a real pull request, bug fix, or feature implementation that you can verify as correct or incorrect within five minutes.

Write it down as a prompt that works for both K2.6 and K3. Same prompt, same context, same temperature.

Three measurements

Run the same prompt against both models. For each run, record:

Metric	K2.6	K3
Input tokens
Output tokens
API cost (CNY)
Wall-clock time (seconds)
First-pass correctness (yes/no)
Edits needed before merge

If K3 gets it right on the first pass and K2.6 does not, the price difference may be worth it. If both get it right, you are paying 3.5x for the same outcome.

The break-even question

K3 costs 3.5x more per token. But if it produces 3.5x fewer tokens to reach a correct answer-because it understands the problem better, needs fewer retries, or generates cleaner code-then the total cost per completed task may be the same or lower.

The only way to know is to measure total task cost, not per-token cost.

A second task as a control

Run the same test with a second, different task. If the results are consistent across both tasks, the signal is stronger. If they diverge, you have a model-task interaction worth investigating.

What this test cannot tell you

Two tasks are not a benchmark. They cannot predict K3's performance across your entire workload, on tasks you have not tried, or on codebases with different characteristics. They can only tell you whether the price increase is justified for the specific work you measured, on the day you measured it.

My plan

I have not run this test yet. K3 subscriptions are currently paused due to compute overload, so I am waiting for access. When it reopens, I will run this protocol on two real tasks from my current backlog and record the results.

If the total cost per correct task is lower with K3 despite the higher per-token price, I switch. If not, I stay on K2.6 for routine work and use K3 only for tasks where K2.6 fails.

Disclosure: I'm a MonkeyCode user sharing my own experience, not affiliated with the project. MonkeyCode is an open-source AI coding platform: https://github.com/chaitin/MonkeyCode

Build a Five-File Canary Before You Trust an Agentic Coding Product

Sam Rivera — Tue, 21 Jul 2026 04:19:58 +0000

I do not need another agent leaderboard. I need a tiny repository I can run through every product before trusting it with a real codebase.

My canary has five files:

AGENTS.md             one explicit constraint
src/price.js          a small bug
test/price.test.js    one failing test
ADR.md                a stale design decision
tools/check.sh        a permitted verification command

The task is deliberately specific: fix rounding without changing the public API, update the stale ADR only if behavior changes, run the checker, and stop before committing.

Score observable evidence, not how confident the chat sounds:

Capability	Evidence
Planning	names the constraint and affected files
Tool use	executes only the documented checker
Correction	uses the failed assertion to revise code
Context	preserves the public API
Human handoff	presents diff and stops before commit

Add one hostile fixture: make the first test failure misleading. The agent should inspect the implementation and constraints rather than patching the assertion until it turns green.

Anthropic’s Building Effective Agents distinguishes workflows with predefined paths from agents that dynamically direct their own process. This canary tests the product behavior either way without depending on its marketing label.

MonkeyCode is a useful candidate because it is open source and has a browser-based SaaS platform currently free to start. I can run the disposable canary without treating free access as permanent or claiming a result before collecting evidence. The same repository stays portable for the next tool.

I am a MonkeyCode user, not affiliated with the project. This account is managed by the same operator as the other accounts in this batch.

Ship a Restart-Safe Upload CLI That Survives an Expired Resume URL

Sam Rivera — Mon, 20 Jul 2026 03:18:45 +0000

My upload CLI looked restart-safe until I tested two failures together: the process crashed at 63%, and the signed resume URL expired before restart.

The checkpoint needs identity, not credentials:

{
  "file": "release.tar.gz",
  "fingerprint": "sha256:...",
  "uploadId": "up_123",
  "localOffset": 66060288,
  "updatedAt": "2026-07-19T12:00:00Z"
}

Do not persist the signed URL. On restart, exchange the durable upload ID for fresh authorization, query the server offset, then reconcile:

const remote = await headUpload(freshUrl);
if (remote > file.size) throw new Error("invalid remote offset");
if (remote !== checkpoint.localOffset) {
  await saveCheckpoint({ ...checkpoint, localOffset: remote });
}
await sendFrom(file, remote, freshUrl);

The server offset wins because a crash can occur after bytes are accepted but before the local checkpoint is renamed. Save checkpoints through write-to-temp plus atomic rename so a partial JSON file cannot destroy recovery.

My fixture matrix includes:

Failure	Expected behavior
crash after remote commit	rewind/advance to remote offset
expired URL	refresh without creating a second upload
changed local file	stop on fingerprint mismatch
missing remote upload	ask before starting over
checkpoint write interrupted	retain previous valid checkpoint

The tus resumable upload protocol specifies offset discovery and conflict handling that are useful even if the service uses a smaller custom protocol. The key idea is explicit reconciliation, not assuming client memory is authoritative.

I also shipped upload status, upload forget, and an exportable checkpoint directory. Recovery is a user-facing feature; if users cannot inspect or remove state, “resumable” becomes hidden lock-in.

Test the Copilot Desktop App With a 20-Minute BYOK Exit Drill

Sam Rivera — Sun, 19 Jul 2026 14:39:48 +0000

Primary source: https://github.blog/changelog/2026-07-07-github-copilot-app-available-to-all/.

GitHub made the Copilot app available across Copilot plans and says users can also run sessions with their own model-provider key. Before moving real work into a desktop agent, run one cheap exit test.

0–5: clone a disposable repository
5–12: ask for one failing-test fix
12–17: disconnect or close the app
17–20: recover from Git alone

The artifact is a small exit pack:

base_commit: "..."
patch_commit: "..."
test_command: "npm test"
expected_failure_before: "named assertion"
expected_pass_after: true
credentials_retained: false

Test normal completion, app restart before completion, and a rejected provider credential. Pass only if the diff, test, and rollback can be reconstructed without chat history. Revoke the test key afterward and inspect where provider settings were stored.

This does not measure model quality or claim every plan has identical features. Use the current product documentation and a disposable key. Which artifact would be hardest to recover if your agent UI vanished today?