Coding agents run in your shell

2026-11-08T00:00:00Z

The .sh in coding.sh is not a pun. A coding agent does its real work in a shell. It reads files, runs tests, greps the tree, stages a commit, starts a server — all of it as shell commands the model decides to run. The model's prose is a plan; the shell is where the plan becomes an action that can pass, fail, or change your repo. That is the layer worth watching, and it is the layer coding.sh records.

Where the work and the risk are

Open any agent session and the shape is the same. A few prompts, a lot of tool calls, and most of the tool calls are shell commands. npm test. git diff. rg TODO. A one-liner that edits a file in place. The interesting moments are all here: the command that failed and got retried without a change, the test that went green only after a test file was edited, the rm that was wider than it looked, the key that ended up on a command line.

coding.sh reads each shell command the agent ran, pairs it with its result, and keeps the diff of what changed. From that it can tell you plain things that are tedious to reconstruct by hand: which commands failed, which ones changed files without a test running afterward, and whether a passing test run was earned or edited into passing.

A hook, not an integration

coding.sh captures through a hook — a small process the agent's own harness runs after each step. The rules it follows are shell-citizen rules. It exits 0 so it can never break the agent. It prints nothing unless the protocol needs a reply. It does no network and no git work. It writes the raw payload to a spool file and returns, well under 50 ms, so the agent never waits on it.

That is the whole install for Claude Code, Codex, Gemini CLI and the rest: a hook line in the agent's config, added by coding.sh init. No SDK, no wrapper around your commands, no proxy in the default path. The agent keeps running exactly as it did.

It is a CLI, so it lives where you do

The tool is a command. You read sessions, usage and diffs in your terminal, next to the agent that produced them. coding.sh sessions, coding.sh usage --by model, coding.sh show <id>. The viewer is the same binary: coding.sh ui serves a local page on 127.0.0.1 when you want to click through a replay, and closes when you are done.

Underneath, coding.sh has zero runtime dependencies. Everything is Node's own built-ins — the SQLite index through node:sqlite, compression through node:zlib. Install is one line:

curl -fsSL https://coding.sh/install.sh | sh

A tool for agents that work in the shell should be a shell tool. That is the one coding.sh tries to be.

Why coding.sh is local-first

2026-11-07T00:00:00Z

An agent session is a record of your work. It holds your prompts, the model's replies, every tool call with its input and output, and the files that changed. Sometimes it also holds a key that ended up in a shell command. coding.sh records all of that, so where the record lives matters.

One folder on your machine

Everything coding.sh captures goes into ~/.coding.sh. Set CODING_SH_HOME to put it somewhere else. Sessions and events go into a SQLite index, index.db, through Node's built-in node:sqlite. Large prompts and tool output go into blobs/, compressed with zstd.

The viewer runs from the same CLI. It binds to 127.0.0.1 and asks for the token in the URL it prints.

Nothing is sent unless you ask

With no sinks configured, no session data leaves your machine. The one default network request is a daily update check: a GET to api.github.com, falling back to registry.npmjs.org. Set CODING_SH_NO_UPDATE_CHECK=1 or [update] check = false to turn it off.

The hook that agents run writes the raw payload to ~/.coding.sh/spool with mode 600 and exits. It does no network work.

To send events somewhere else, add a sink. A sink sends metadata unless you set mode = "full": ids, timestamps, kinds, durations, token counts and short labels. Prompts, code and tool output stay on your machine.

# ~/.coding.sh/config.toml
[[sinks]]
kind = "otlp"                      # or "http"
endpoint = "http://localhost:4318"
mode = "metadata"                  # default; "full" sends content

Secrets are redacted before they are written

Redaction runs at ingest, before anything reaches the index, the blobs or a sink. The built-in rules catch private keys, vendor API keys and tokens, JWTs, and bearer and basic auth.

Redaction keeps a secret out of the store, but the agent and its model provider still saw it. So a session that held a vendor token gets the secret:exposed tag, and this lists the sessions whose credentials to rotate:

coding.sh sessions --flag secret:exposed

If a value got past redaction, coding.sh purge --literal leaked.txt replaces every stored copy with [redacted:purged].

A cloned repo cannot widen it

A .coding.sh/config.toml inside a repository can add redaction rules or switch capture to metadata mode. It cannot add sinks or move the store. Opening a repository you cloned does not send your sessions anywhere.

Storage, sinks and privacy lists everything that is captured and every setting that changes it.
Concepts defines the words coding.sh uses: sessions, events, flags and the rest.

coding.sh blog