DEV Community: Nic Flemmer

Do you run the checks before or after merging main into an agent's branch?

Nic Flemmer — Wed, 28 Oct 2026 15:03:17 +0000

A coding agent's branch is cut from main, and main keeps moving while it works. By the time the agent says it's done, the branch is a few commits behind.

There are three places to run the tests before the work goes in.

On the branch as the agent left it. Fast, and it tells you the agent's own work passes. It tells you nothing about how that work sits with whatever landed on main in the meantime.

After merging main into the branch. This is what I settled on. A clash between two agents' changes shows up on the branch, where the agent can still fix it, rather than on main. The cost: the checks run again every time main has moved.

Only on main, after the merge. Simple, but a failure now sits on main and you're reverting or fixing forward.

In Styx, the app I'm building, Land does the middle one: it brings main into the task's branch, runs the project's checks there, and only merges if they pass. If a step fails, nothing reaches main. It merges rather than rebases, so the agent's undo points stay valid.

Where do you run them: on the branch as it was, after bringing main in, or only on main? And does that change when two agents are working at once?

Your coding agent CLI may approve its own tool calls by default

Nic Flemmer — Tue, 27 Oct 2026 15:06:03 +0000

I added Goose and Amp to a tool that runs several coding agents. The most useful thing I learned wasn't about the protocol. It was the defaults.

Goose's default mode approves tool calls automatically. If you start it through a wrapper that doesn't set a mode, it runs commands without asking anyone. So I set the mode per process instead of relying on whatever is in the user's Goose config. Default, accept-edits and auto all use Goose's approval mode, so tool calls ask. Only the permission mode literally called bypass picks automatic approval, and none of it touches the user's own Goose configuration.

The second surprise was Goose's chat-only mode. It disables all tools, reads included. A plan mode you'd expect to still read your files doesn't, so mapping 'plan' to it means the agent can only talk.

Amp went the other way. Its streaming output has no documented way to answer an approval from outside, so approvals stay in its own terminal. Its plan and don't-ask modes reject every tool, reads included, and only bypass asks for automatic approval.

What I do with any new agent CLI now: before wiring up anything else, run it once in an empty directory and see what it does with a tool call by default. Two agents gave me two very different answers, and neither was in the first page of the docs.

Which of your agent CLIs would run a command without asking, if you started it the way you usually do? I'm building Styx, where this came from.

Message an agent mid-turn: interrupt it or queue the message?

Nic Flemmer — Mon, 26 Oct 2026 15:02:21 +0000

You give a coding agent a task, watch it start going the wrong way, and type a correction. What should happen to that message?

There are two designs. Interrupt: the message goes in straight away and the agent changes course. Queue: it waits, and the agent reads it when the current turn ends.

Interrupting is quicker when you've caught a mistake early. But the agent may be halfway through an edit, and a correction can land at a bad moment. Queueing is safer for the work in progress, but a wrong turn keeps running until it's done.

Which one you get depends on how the agent exposes itself. In Styx, the app I'm building, Codex runs over codex app-server, so it takes a message at once and adjusts. Claude Code, Gemini CLI, Cursor's agent and OpenCode hold the message and send it when the turn ends, and a Send now button skips the wait.

If you could pick, would you want messages to interrupt by default, or queue by default? Does the answer change with how long the turn is?

Your coding agent hits its usage limit halfway through a task. Wait or switch?

Nic Flemmer — Sun, 25 Oct 2026 14:02:23 +0000

Most coding agent plans have a usage limit, and it has a way of running out in the middle of something rather than between tasks.

You have roughly three options. Wait until it resets. Pay for more. Or hand the rest to a different agent.

Waiting keeps everything the agent had worked out, but it might cost you hours. Switching gets you moving right away, but the second agent starts cold: it sees the repo and your prompt, and the first agent's partial work only if you pass it along.

In Styx, the app I'm building, I made the choice visible instead of burying it: when a plan is out, it shows when the limit resets, or sends the same ask to another agent.

So, when your plan runs out mid-task, what do you do? And if you switch agents, does the second one start from your original prompt, or from whatever the first one had done by then?

What I set up so a stranger could send a first pull request

Nic Flemmer — Sat, 24 Oct 2026 16:02:31 +0000

Styx went open source on 9 October (Apache-2.0). 'Contributions welcome' in a README tends to get nothing, so I tried to make the first step small and specific instead.

There are two self-contained ways in: add support for another coding agent, or add another deploy target. Each has a guide with a worked example and a checklist. Matching issues are labelled 'good first issue': Aider, Goose and Amp for agents, and targets such as Netlify. The repo's CLAUDE.md is written for coding agents and people alike, so the conventions live in one file.

I also promised that new issues and pull requests get a first reply within two working days. A pull request nobody answers is a worse experience than none, so that one is for the sender's sake.

A contributor has now sent a draft Cloudflare adapter. They'd found that the way the app hands out credentials today can't limit a broad Wrangler token to one account, one Worker and one command. So the draft adds the groundwork (account and Worker selection, read-only Worker discovery, a command classifier) and keeps Cloudflare switched off until that's solved.

What I'd tell anyone else: pick two entry points, write them as if for a stranger, and answer fast.

What made you send your first pull request to a project you didn't know? And what put you off the ones you skipped?

Keep undo points in hidden git refs, not commits

Nic Flemmer — Fri, 23 Oct 2026 14:02:30 +0000

I wanted an agent's turns to be undoable one at a time, without touching the branch history. Committing after every turn would do it, but then your branch is full of commits you didn't write, and they'd go out with your next push.

What I do instead: at the start and end of every turn, the app records the state of the task's files as a checkpoint and keeps each one as a hidden git ref under refs/styx/checkpoints/. A ref outside refs/heads/ isn't a branch, so it doesn't show in git branch, plain git log doesn't list it, and a normal git push doesn't send it. It doesn't touch your index or your commits either.

You can see them with plain git:

git for-each-ref refs/styx/checkpoints/

Because they're real refs, git's garbage collection keeps the objects they point to, so nothing needs a separate store.

Undo then works from those two snapshots: take what a turn changed and reverse just that, leaving later turns and your own edits alone. If a later change touched the same lines, it refuses rather than guess.

The trade-offs: the refs live in your clone only, so teammates don't get them, and they're not a backup. They're cleaned up when a task is archived. And anything that rewrites history under them (a rebase of the branch, say) would orphan them, which is why the app merges main into a task instead of rebasing.

Have you tried hidden refs, git notes or stash for this kind of thing? What bit you?

An append-only, hash-chained audit log in SQLite, and a script to check it

Nic Flemmer — Thu, 22 Oct 2026 15:02:26 +0000

When a coding agent can ask for production access, the question afterwards is simple: who touched production, with what, and why? Styx answers it with an audit log on your machine. This post is about how that log is built, what it does and doesn't protect against, and a short script you can run to verify it.

What goes in

Every time an agent asks for access, and every time access is granted, used, denied, revoked or expires, one row is written. Connecting or removing a target, changing a policy and opening a pull request are rows too. Each row carries:

the actor: you, the system (a policy or a timer), or the agent by name
the target, the scope and the duration
the agent session and the worktree it came from
what triggered it: for a use, the command itself, like $ vercel deploy --prod
the policy that decided it, if one did
detail such as the agent's reason, and whether you verified with Touch ID, Windows Hello or your password

Before a row is written, anything shaped like a secret is scrubbed out of commands, reasons and labels, so a token an agent pasted into a command line doesn't end up in the log.

Append-only means the database says no

The log is a table in the local SQLite database. Triggers on the table abort any update or delete. Nothing in the app edits a row, and rows are only written through one function, AuditService.append. When a grant is revoked, Styx doesn't change the 'granted' row; it adds a 'revoked' row.

The chain

Each row has a sequence number, the hash of the row before it (prev_hash) and its own hash: a SHA-256 of the previous hash and the row's contents. Change any field of any row, or remove one from the middle, and the chain breaks from that point on.

Verifying it yourself

The app has no verify button yet, but the data is just a table. Export it read-only with sqlite3 (3.33 or later, for -json) and pipe it into Node:

sqlite3 -readonly -json ~/Library/Application\ Support/Styx/styx.db \
  "SELECT * FROM audit_entries ORDER BY seq" | node verify-audit.mjs

With this saved as verify-audit.mjs:

import { createHash } from 'node:crypto';

const chunks = [];
for await (const chunk of process.stdin) chunks.push(chunk);
const rows = JSON.parse(Buffer.concat(chunks).toString('utf8') || '[]');
const camel = (k) => k.replace(/_([a-z])/g, (_, c) => c.toUpperCase());

let prev = '';
for (const r of rows) {
  const row = {};
  for (const [k, v] of Object.entries(r)) if (k !== 'hash') row[camel(k)] = v;
  const canonical = JSON.stringify(row, Object.keys(row).sort());
  const hash = createHash('sha256').update(prev).update('\n').update(canonical).digest('hex');
  if (row.prevHash !== prev || hash !== r.hash) {
    console.log(`Chain broken at entry ${row.seq}`);
    process.exit(1);
  }
  prev = r.hash;
}
console.log(`Chain intact: ${rows.length} entries`);

It prints Chain intact with the number of entries, or the first row where the chain breaks. The database is at ~/Library/Application Support/Styx/styx.db on a Mac, %APPDATA%\Styx\styx.db on Windows and ~/.config/Styx/styx.db on Linux.

What the chain can't do

The chain shows that rows weren't edited one at a time after the fact. It doesn't stop someone who can write to your files from rewriting the whole log and recomputing every hash. If that matters to you, copy the latest hash somewhere else now and then; a later rewrite of the history before it won't match.

It's also a record, not a barrier. Styx is a guardrail, not a sandbox: agents run as you, and one that deliberately goes around Styx's tools isn't stopped by the log or by anything else in it. What the log gives you is a trustworthy account of everything that did go through Styx.

The code is Apache-2.0 at github.com/NicholasFlemmer/styx-app.

What's new in Styx 0.4.17

Nic Flemmer — Wed, 21 Oct 2026 19:03:30 +0000

Styx 0.4.17 is out. Styx runs Claude Code, Codex, Gemini CLI, Cursor and OpenCode on all your projects in one window, each task on its own branch, and agents ask before they touch production. Free and open source (Apache-2.0); Mac, with Windows and Linux in beta.

What changed:

Stop offering unapplied editor preference imports (#3) and thank @delusional-whispers in the README.
Bake Ponytail coding guidance into all five agents with MIT attribution and prepare release 0.4.17.

Full release notes and downloads: https://github.com/NicholasFlemmer/styx-app/releases/tag/v0.4.17

Code: https://github.com/NicholasFlemmer/styx-app · Site: https://heystyx.com

If you run into anything, issues and discussions on GitHub are the best place; I read all of them.

Let the agent work out your test command once, then write it down

Nic Flemmer — Wed, 21 Oct 2026 14:02:36 +0000

An agent can read a repo and work out how it checks itself: usually a typecheck, the tests and a linter, taken from the package scripts. It's good at that. It's a poor thing to depend on every time you want to merge.

So in the app I'm building, Styx, the agent does it once. The first time you land a task in a project whose checks aren't known, the task's agent gets a turn to work out the command, run it until it passes, and report it back through a remember_command tool. After that the same command runs before every landing, with no agent involved.

The answer is saved in the project's .styx/project.json as checks.command, not in some hidden app state. That matters for three reasons. A person can read it and see what 'passing' means here. Everyone on the project shares it. And if it's wrong, you fix it by editing one line, or clear it and the next landing asks the agent again.

One guard: a command that looks like it carries a secret is refused, because that file is committed.

When it doesn't apply: if the agent can't work the command out, the landing goes ahead without checks and says so ('no checks ran: none are known for this project'), rather than blocking you. And the stored command goes stale the day someone renames a script, so treat it like any other config.

The general version: let the agent discover, then write the result somewhere a human can read and edit. Do you cache what your agents work out, or let them rediscover it each time?

Should two coding agents ever edit the same file?

Nic Flemmer — Tue, 20 Oct 2026 15:02:33 +0000

Say you split a feature between two coding agents: one builds the /orders endpoint, the other builds the page that calls it. Each works on its own branch in its own copy of the repo, so neither can overwrite the other's files while they work.

The collisions come anyway, usually in the same few places: package.json, a lockfile, a migration, a route table.

In the tool I'm building I went for warnings rather than locks. When one agent changes a file the other has already changed, both chats get one line naming the other task. For those shared files the line is firmer and asks the two to agree on one owner first. The agents can also message each other, so they can settle it themselves. And if two branches still conflict when main comes in, the conflict goes back to the agent that made it, with both sides' intent.

The case for a hard lock is that it's simple: the first agent to touch a file owns it until it lands. The cost is that the second agent has to wait or work around a file it needs, and a lock held by an agent that's stuck blocks everyone.

So I'm curious how others handle it. If you run more than one agent on a codebase, do you split the work so files never overlap, let them collide and sort it out at merge time, or lock files? And what do you do about the shared ones, like lockfiles and migrations?

(I'm building Styx, an open-source app that does the warnings part.)

What's new in Styx 0.4.16

Nic Flemmer — Tue, 20 Oct 2026 08:03:33 +0000

Styx 0.4.16 is out. Styx runs Claude Code, Codex, Gemini CLI, Cursor and OpenCode on all your projects in one window, each task on its own branch, and agents ask before they touch production. Free and open source (Apache-2.0); Mac, with Windows and Linux in beta.

What changed:

fix: use shared settings footer copy in simulation
Fix the design canvas startup white screen when an iframe has no HTML root; prepare 0.4.16.

Full release notes and downloads: https://github.com/NicholasFlemmer/styx-app/releases/tag/v0.4.16

Code: https://github.com/NicholasFlemmer/styx-app · Site: https://heystyx.com

If you run into anything, issues and discussions on GitHub are the best place; I read all of them.

What's new in Styx 0.4.15

Nic Flemmer — Mon, 19 Oct 2026 18:03:58 +0000

Styx 0.4.15 is out. Styx runs Claude Code, Codex, Gemini CLI, Cursor and OpenCode on all your projects in one window, each task on its own branch, and agents ask before they touch production. Free and open source (Apache-2.0); Mac, with Windows and Linux in beta.

What changed:

Add disabled Cloudflare adapter and strict operation plans
List every agent and deploy target where Styx names them
Thank contributors in the README
Retry a design screen that fails to load, and keep e2e failure snapshots in CI
Add a Do not disturb switch to Settings and the palette

Full release notes and downloads: https://github.com/NicholasFlemmer/styx-app/releases/tag/v0.4.15

Code: https://github.com/NicholasFlemmer/styx-app · Site: https://heystyx.com

If you run into anything, issues and discussions on GitHub are the best place; I read all of them.