DEV Community: Srinivas Kondepudi

Five Chron updates for AI audit trails you can inspect

Srinivas Kondepudi — Sun, 25 Oct 2026 19:59:44 +0000

An AI tool answering a prompt and an audit record being saved are two different events.

That distinction has shaped our recent work on Chron, a local-first logger for AI interactions. We want developers to inspect what was recorded, understand what a verification result establishes, and recover their evidence when something goes wrong.

Here are five capabilities shipped across recent releases, available in Chron 0.1.64.

1. Capture before release, without asking the model to log

MCP logging depends on the client calling a tool. Instructions can request that call, but they cannot make it inevitable.

chron run introduces a different boundary. It records the child's controlled stdin, stdout and stderr in a local journal and makes the covering records durable before forwarding input or releasing output. If capture fails, it stops forwarding and releasing rather than quietly continuing without a record.

For a small example:

npm install -g chron-mcp@0.1.64
chron run -- node -e "console.log('hello from chron')"
chron history
chron verify --journal

The wrapper also attempts to project the run into the database. If projection fails independently of capture, chron project is the retry path.

The limit matters: this covers streams controlled by the wrapper. It does not force anyone to use the wrapper or capture everything a client does through files, subprocesses or network calls. Runs recorded with reduced directory durability do not receive the full enforced:wrapper classification.

2. Backup and recovery that checks the evidence

A logger should have a recovery path before it has a destructive command.

Chron now takes SQLite snapshots using VACUUM INTO, with a separate manifest describing the snapshot. Restore checks the file digest, database integrity and recorded evidence chains before installing the restored copy. Recovery drills exercise verification without replacing the live database.

Confirmed pruning requires an explicit backup destination and refuses to delete if that backup fails.

Backups and signed exports remain different tools: one restores a database; the other lets someone verify a portable evidence bundle. The backup manifest is unsigned, so its recorded creation time is not independently attested.

3. Reconcile what the client recorded with what Chron holds

chron reconcile compares local Claude Code transcript records with inspected Chron evidence. It is read-only: it does not import, merge or silently upgrade the provenance of a session.

The streaming reader can inspect large transcript files without retaining the whole file in memory. The comparison remains sampled, up to 200 messages per transcript, and reports its inspected scope and limits.

An unmatched record means no correspondence was found within that comparison. It is not proof that someone bypassed logging, and the correspondence fraction is not a capture-completeness score.

4. OpenTelemetry export with delivery receipts

Chron supports operator-initiated OTLP/HTTP JSON trace export for sessions and messages. Conversation content is excluded by default.

The useful part is distinguishing outcomes. A collector refusing an export is not the same as a connection failing before delivery. A request received by a collector that never answers has an uncertain outcome.

chron otel receipts exposes the recorded delivery state rather than flattening those cases into a success tick. This is manual trace export, not automatic telemetry, metrics or log export. A collector response is not proof of permanent retention.

5. HTTP transport defaults that are explicit

For deployments using MCP over HTTP, Chron 0.1.64 requires authentication and binds to loopback by default. It validates Host and Origin, and non-loopback binding requires explicit configuration.

The stdio path remains separate and does not require an HTTP API key.

These are specific controls, not a blanket security claim. Dependency hardening is ongoing and is being scoped separately from feature work.

Verification should explain its boundary

The common thread is keeping the claim close to the evidence.

A journal chain can establish internal consistency; an unanchored chain is not proof that nobody rewrote it. A successful package test does not establish that every AI client will invoke Chron. A local record does not establish that every interaction was captured.

Our latest published-package regression passed 44 release checks and nine streaming checks. Real authenticated client acceptance remains a separate, unfinished test leg, not something those numbers establish.

Chron is available on npm, with source and documentation on GitHub.

For teams using AI developer tools: which gap is hardest today: dependable capture, identifying missing records, or independently verifying the evidence you already have?

Chron crossed 11,000 downloads. Here's what the feedback is teaching us.

Srinivas Kondepudi — Mon, 19 Oct 2026 15:26:55 +0000

Chron has reached 11,148 total npm downloads.

Thank you to everyone who has installed it, tried it in a real workflow, asked difficult questions, or shared feedback across developer communities and platforms.

AI work deserves a record.

One important distinction before anything else: downloads are not unique users. Repeat installs, upgrades and automation all contribute. This is a distribution milestone, not a claim about how many people actively use Chron.

Why we're building Chron

AI-assisted work is happening across terminals, editors and chat clients. When someone later asks what was requested, what the assistant returned, and when the interaction happened, reconstructing the answer can be surprisingly difficult.

Chron is a local-first tool for recording AI interaction evidence and inspecting that record later. The aim is straightforward: make the evidence useful without claiming it establishes more than it does.

The most useful feedback hasn't been about adding another chart. It has been about the boundary between a tool being configured and an interaction actually being recorded.

Three distinctions that matter

Configured is not captured. An MCP connection can exist without the client making a logging call. Instruction-based logging still depends on the AI client choosing to call the tool. It isn't mandatory capture.

Recorded is not complete. Having a session in the database doesn't establish that every interaction was recorded. Chron's Claude Code transcript reconciliation compares inspected transcript records with Chron evidence and reports the correspondence it finds. Its comparison is sampled, so that result must not be presented as a completeness percentage for the entire conversation.

Accepted is not retained. When an operator exports traces through OTLP/HTTP, collector success establishes acceptance of the payload, not that the platform stored it. Chron's export receipts preserve that distinction.

These aren't just wording preferences. They change how useful the record is when someone relies on it.

Capture without asking the model to remember

Chron also provides a wrapper path:

chron run -- <your-cli> <arguments>

For the stdin, stdout and stderr channels it controls, the wrapper records data in its local journal before forwarding input or releasing output. This doesn't require the model to make a logging tool call.

That guarantee has a boundary: it does not force someone to use the wrapper, and it does not capture arbitrary file writes, subprocess activity, network traffic or direct-terminal access outside those controlled channels.

After projection, the session can be inspected through Chron's ordinary history and verification commands. Verification compares the projected messages with the journal evidence rather than trusting an enforcement label in a database field.

The journal's hash chain establishes internal consistency. Because its head is not independently anchored, it is not proof that nobody could rewrite the whole chain.

Three released features to try

1. Inspect capture scope, then wrap a CLI. Start with the scope rather than assuming everything is covered:

chron run --scope
chron run -- <your-cli> <arguments>
chron verify --journal
chron history

Replace the angle-bracket placeholders with your CLI and its arguments. The wrapper captures controlled terminal channels, not every action the client takes. CLI compatibility varies; this isn't a promise of support for every interactive client.

2. Compare Claude Code transcripts with Chron evidence.

chron reconcile
chron reconcile --json

This is read-only and currently specific to Claude Code transcripts. Up to 200 comparable messages per transcript are sampled; larger-file streaming doesn't remove that comparison limit. Correspondence is not an overall capture-completeness score.

3. Make a database backup and rehearse verification without replacing the live database.

chron backup --output=./chron-milestone-backup.db
chron restore --from=./chron-milestone-backup.db --drill

Choose a new output path. The drill checks the snapshot without installing it. A database backup is not a backup of separate journal files or signing keys; preserve those separately when planning recovery.

What we'd like feedback on next

We're continuing to work on reliability, capture coverage and making those boundaries easier to understand across AI workflows. Support varies by client and capture path; a configured integration is not a blanket guarantee.

If you've tried Chron, which client are you using, and where does the record fall short of what you need? A concrete workflow, a confusing output, or an interaction that wasn't recorded is more useful than a broad feature vote.

You can find the package on npm and the public repository on GitHub.

Thank you for helping turn a download milestone into better engineering questions.

AI audit logging should not depend on AI remembering to log

Srinivas Kondepudi — Tue, 13 Oct 2026 08:12:22 +0000

An AI client can have the right logging instructions, the right MCP configuration, and a reachable audit server, and still leave you with no record of the conversation.

The model might skip a tool call. A permission policy might refuse it. A run might end before the logging call happens.

We encountered these failure modes while testing Chron. They led to a change in where capture happens.

Chron 0.1.62 introduces chron run: a wrapper that records the stdin, stdout, and stderr channels it controls before forwarding or releasing their bytes. Logging on that path does not require the model to call Chron.

Move capture into the execution path

Chron is a local-first tool for recording AI interactions and inspecting the evidence they leave behind. Its published npm package is available for end users; the source is visible for review under the project's license.

Its MCP integration remains useful. A cooperating client can record messages and structured events, including tool calls and code changes. But a request to log is not an enforcement boundary.

The wrapper introduces a different path:

Operator input -> journal write + fsync -> child stdin
Child stdout   -> journal write + fsync -> terminal
Child stderr   -> journal write + fsync -> terminal

The process doing the writing also controls forwarding and release. It waits for the covering write and fsync to succeed. If a capture write fails, it stops forwarding, withholds pending output, and terminates the direct child.

That ordering is the feature. Recording the same bytes after displaying them would leave a window in which the response reached the operator and the audit record did not.

Try the capture path

Install the released package:

npm install -g chron-mcp@0.1.62
chron version

Print the scope before wrapping a client:

chron run --scope

Here is a small example that needs no AI account. It checks the input/output path with a child process that echoes what it receives:

printf 'hello chron\n' | chron run -- node -e \
  'process.stdin.on("data", b => process.stdout.write(b))'

For a headless Claude Code invocation that reads its prompt from stdin:

printf 'Explain this repository in three sentences.\n' | chron run -- claude -p

Client authentication and permissions still apply. This release controls inherited stdio pipes; it is not a promise of compatibility with every interactive terminal UI. Text supplied in command-line arguments is recorded as command metadata rather than as an input message.

Inspect the resulting evidence:

chron history
chron verify --journal
chron verify <session-id>

Capture first, query second

Wrapped runs go into an append-only, hash-chained local journal. Chron then projects completed runs into its session database for history and reporting.

This ordering matters when the database is unavailable. A projection failure is reported separately from capture. The journal retains the evidence, and replay can reconstruct the session later:

chron project

Replay is transactional per run and idempotent. Repeating it does not create another copy of an already projected session.

The default journal is ~/.chron/capture.jsonl; the default database is ~/.chron/chron.db. Both remain under the operator's control.

What the enforcement label means

Chron distinguishes two questions:

Provenance: how did Chron obtain this evidence?
Capture mode: what required recording on this path?

A client calling an MCP logging tool and a wrapper intercepting stdio can both produce witnessed evidence. They have different capture guarantees.

A fully durable wrapped run can support enforced:wrapper. Session verification checks its journal binding, run structure, and projected message content against the journal. Setting a label in database metadata is insufficient.

Reduced-durability runs are explicitly distinguished and do not qualify for the same full guarantee.

The boundary is narrower than "everything the AI did"

The wrapper controls stdin, stdout, and stderr. It does not capture file access, network requests, independent subprocess activity, or a terminal the client opens directly. Nor does it prevent someone from launching the client outside Chron.

There is another distinction to keep clear: an internally consistent hash chain is not proof that nobody rewrote it. Someone able to replace the entire unanchored journal can recompute its hashes. Chron does not currently sign journal heads.

The label therefore describes the controlled capture path. It is not a certification of every AI action or an organization-wide enforcement policy.

Test the failure paths too

The useful tests were not just "does the output appear?" They were:

Was its covering record flushed before it appeared?
Did a short write or failed sync stop release?
Did an interrupted run remain distinguishable from a completed one?
Could database projection fail without losing captured evidence?
Did an edited projection lose its verified enforcement claim?

An independent manual regression against the published 0.1.62 package exercised capture, replay, rotation, signing, recovery, imports, and collector delivery. It also found two OTEL guidance issues: collector rejection was described as a request not reaching the collector, and retry guidance overstated deduplication guarantees. Both remain findings in that released version.

That is the standard we want for an evidence tool: its claims should be small enough to test, and its limits should be visible alongside them.

Chron is available on npm, with the public project and documentation on GitHub.

If you try the wrapper, which client and failure scenario would you test first?

We're Enabling SaaS for CLAIIM. Sovereignty Still Matters.

Srinivas Kondepudi — Fri, 09 Oct 2026 20:04:22 +0000

Trying an AI governance product should not require a production deployment decision on day one.

That is why we are enabling SaaS for CLAIIM: to give teams an easier way to explore the product, experiment with agent workflows, and understand where runtime governance fits before committing to a deployment.

But easier access should not make deployment control an afterthought.

SaaS is an easier way to start. Sovereignty remains a design priority.

This is a direction update, not a general-availability announcement or a promise that every hosting and residency option is already available.

The problem is bigger than another AI chat interface

An organization might use several AI tools across engineering, operations, and internal workflows. Giving everyone another place to chat does not, by itself, govern what those agents can do.

The harder questions begin when an agent wants to act:

Who is accountable for this agent?
What authority has it been delegated?
Which policy applies to this action?
Can it proceed, must it stop, or does it need human approval?
What was actually observed afterward?

CLAIIM is the runtime governance layer for AI agents: establishing who is acting, what they may do, whether an action can proceed, and what evidence remains afterward.

The distinction matters: control the agent's capabilities and execution paths, not merely its conversation.

A prompt asking an agent not to deploy to production is an instruction. A deployment endpoint that rejects requests without the required authorization is a boundary.

What we want SaaS to make easier

Before a team evaluates governance infrastructure, it needs to see the workflow.

Our goal with SaaS is to reduce the setup needed to explore agent identities, skills, policies, approvals, and the evidence trail in the CLAIIM console.

A useful first experiment does not need production credentials. Start with a synthetic workflow and ask:

Can we identify the acting agent and the accountable human?
Can a policy distinguish routine work from sensitive work?
Can a sensitive request enter an approval workflow?
Can we follow the decision and recorded outcome afterward?

That gives developers and security teams something concrete to evaluate together, before connecting a real customer database or a deployment system.

It also makes an important conversation possible early: where should this run when it becomes part of our production environment?

A concrete example: an agent requests a deployment

Consider an agent preparing a release. The following is a conceptual workflow, not an SDK example or a claim that every deployment platform is integrated:

Agent requests an action
        |
        v
Resolve identity, delegated scope, and applicable policy
        |
        v
Runtime decision: ALLOW / DENY / HOLD
        |
        +-- DENY: reject the governed request
        |
        +-- HOLD: require the configured human approval
        |
        +-- ALLOW: permit the controlled execution path
                         |
                         v
                 Record the observed result

In CLAIIM, configured HOLD actions support human approval, including one-person or ordered two-person approval. That does not mean every action requires a human; the applicable policy determines when approval is needed.

There is another qualification that should never disappear in a product demo: an ALLOW or DENY decision is not automatically enforcement.

If the agent can bypass the governed path using another credential or an unrestricted network route, the organization has a policy decision, not a complete execution boundary. Stronger enforcement depends on the surrounding credential, tool, and infrastructure controls too.

Likewise, an HTTP success response is not independent proof that the intended downstream state exists. A recorded outcome and a verified outcome are different things.

Our governing rule is:

CLAIIM must never represent a decision as enforcement, or a reported outcome as verified evidence.

SaaS does not change that rule.

Sovereignty is more than a hosting label

For us, sovereignty means taking deployment and operational authority seriously. It requires concrete answers about:

Where governance data is stored and processed.
Who administers the deployment and can access its records.
How credentials and sensitive inputs are handled.
Which external services receive data.
How retention, export, and deletion work.
What happens when the governance service is unavailable.

Those are evaluation questions, not a list of capabilities we are claiming every SaaS configuration already satisfies.

A hosted trial may be a useful place to learn with synthetic data. Production adoption needs a separate assessment of the deployment, data flows, and enforcement paths involved.

Sovereign deployment remains a priority as we enable SaaS. Convenience should help a team discover the product, not silently decide its long-term trust model.

The console operates the governance layer

The CLAIIM console brings together agents, organizations, skills, policies, grants, governance packs, gateway configuration, users, access, approvals, Chron evidence, proof exports, and settings.

These screens help teams inspect and operate governance. They are not the boundary on their own.

The product direction remains:

The Runtime Gate is the product. The Console operates it. The Workspace is an optional experience built on it.

That keeps us focused on governed actions and evidence rather than competing to become everyone's universal AI interface.

Easier to try. Deliberate about trust.

We want teams to reach their first useful governance experiment sooner, then make an informed decision about production deployment.

That is the purpose of enabling SaaS for CLAIIM.

Make AI easy to try. Keep authority yours.

If you are evaluating agent governance, what would you test first: delegated authority, approval workflows, execution boundaries, or the evidence trail?

Learn more at claiim.io.

Chron passed 10,000 npm downloads on September 30th. 10,158 as of this morning

Srinivas Kondepudi — Sun, 04 Oct 2026 21:14:21 +0000

Chron passed 10,000 npm downloads on September 30th. 10,158 as of this morning, five months after the first publish on May 8th.

I build a tool whose only job is to tell the difference between this was recorded and this was verified. So before writing a milestone post, I pointed it at the milestone.

The number did not survive.

What the number is

Here it is, and you can run this yourself:

curl -s "https://api.npmjs.org/downloads/range/2026-04-01:2026-10-04/chron-mcp" \
  | python3 -c "import json,sys; print(sum(x['downloads'] for x in json.load(sys.stdin)['downloads']))"
# 10158

That is a real figure from npm's own API. I am not disputing it. The question is a different one: what does it establish?

What the number establishes

Almost nothing about whether anyone uses Chron.

Here are the six biggest download days in its history:

2026-05-08   630
2026-07-14   531
2026-08-13   519
2026-05-12   457
2026-07-09   403
2026-05-28   369

And here is what I published on each of those days:

2026-05-08   0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5
2026-07-14   0.1.32, 0.1.33
2026-08-13   0.1.50, 0.1.51, 0.1.52
2026-05-12   0.1.9, 0.1.10, 0.1.11, 0.1.12
2026-07-09   0.1.30, 0.1.31
2026-05-28   0.1.18, 0.1.19, 0.1.20

Six for six. Every record day is a day I pushed a release. The all-time peak is launch day, before anyone had heard of it.

The monthly shape says the same thing. The biggest month was the month I shipped the first version:

2026-05    2523
2026-06    1134
2026-07    2307
2026-08    2294
2026-09    1758

Strip the release-day spikes and the median day over the last thirty days is 34.5 downloads. Forty-five of the last hundred and eighty-seven days had zero.

So: a number that goes up when I act, and sits near thirty-five when I don't.

Marking the inference

Now the part I have to be careful about, because it is the whole point of the post.

I believe most of those spikes are registry mirrors, vulnerability scanners and CI caches reacting to a new version. That belief is reasonable. It is also an inference, and npm's public API gives me no way to test it — there is no breakdown by client, no distinction between a human running npm i and a crawler indexing a tarball.

So the honest summary is not "10,000 downloads are bots". It is:

Established: 10,158 tarball fetches. Every peak day is a release day.
Inferred: much of the volume is automated.
Unknown: how many people installed Chron and kept it.

Three categories, and the headline number lives in the weakest one. A milestone post that printed "10,000 developers" would have moved a fact from the third row into the first by writing a sentence.

Why I care about this specific mistake

Because I have spent the last two weeks finding it in my own code, over and over, in exactly one shape:

A check confirmed something was present, and reported it as a claim that it worked.

The clearest example shipped in the release I was testing when I started writing this.

Chron now has chron restore --drill — a recovery rehearsal. It verifies a backup, reports what the backup is missing relative to your live database, and touches nothing. It ends with this line:

Drill only. The live database was not touched.

I measured that sentence. I built a database whose write-ahead log held a committed transaction, killed the process so the log was left unrecovered, hashed all three SQLite files, ran the drill from the packed tarball, and hashed them again:

before   db=cba17c04/163840   -wal=e854fde3/12392   -shm=b7fc33da/32768
after    db=35bc3010/163840   -wal=ABSENT           -shm=ABSENT

The main file's digest changed. Both sidecars were deleted. A -wal holds transactions that are committed but not yet folded into the main file, so for a few hundred milliseconds that drill was the single most dangerous command in the product — and it said it had done nothing.

The cause is not a careless UPDATE. Reading a write-ahead log that needs recovery requires writing: SQLite has to rebuild the log index to see what the log contains, and the last connection to close checkpoints the log into the main file and removes the sidecars. I tried PRAGMA query_only = ON. I tried libsql's readonly: true. I measured both against a killed database. Both checkpointed. Recovery is not a statement, so a statement-level guard cannot reach it.

The fix is unglamorous: copy the database and its log to a scratch path, read the copy, delete it. The live files are then provably untouched, at the cost of temporary disk.

BEFORE   db=89d729fb/163840   -wal=531a0aee/12392   -shm=7cb7830f/32768
         ! 1 of 2 live session(s) are absent from this backup
         Drill only. The live database was not touched.
AFTER    db=89d729fb/163840   -wal=531a0aee/12392   -shm=7cb7830f/32768

Same three digests. And still reading through the log — it found the session that exists only in the log, so it is not passing by refusing to look.

The test that proved nothing

One more, because it is the same bug wearing a lab coat.

My first regression test hashed the files before and after a drill and asserted they matched. It passed. Then I restored the broken code to check the test would catch it.

It still passed.

Inside a test runner the process never exits, so the connection never closes, so the checkpoint never happens. The test was watching exactly the right place and would never have seen anything occur. It took a child process — and an assertion on the -shm digest, the one part of the damage that is visible in-process — to make it real.

A test that cannot fail is a claim, not a check. Which is the same sentence as the one about downloads.

What I would rather count

Chron is a local-first audit log: it records what your AI coding tools actually did, on your machine, in a database you own, with hash-chained records you can verify offline. Nothing leaves your disk unless you explicitly export it.

That design is the right one, and it means I cannot see usage. No telemetry, no phone-home, no install ping. The number I can see is the one npm hands me, and the number I would actually want — how many people ran a verify and got a clean chain back — is one I have deliberately made it impossible for myself to know.

I am not going to fix that by adding telemetry to an audit tool. So the honest position is that I have a download count, I know what it is worth, and I am going to say so rather than round it up into a victory.

The actual milestone

Five months. Forty-five releases. One recurring defect shape, now written on the wall where I can see it.

The operating principle for the product is Chron records, it does not certify — it hands you evidence and leaves the judgement to you. It would be a strange thing to write that on the box and then certify my own growth from a number I cannot audit.

10,158 tarball fetches. Median real day, about thirty-five. Thanks to whichever of you are the thirty-five.

Every bug we found this release was the same bug

Srinivas Kondepudi — Thu, 01 Oct 2026 17:40:29 +0000

I build an audit tool. Its whole proposition is that its records can be trusted. So the defects we found in the last release were embarrassing in a specific way: almost every one of them was the tool claiming something it had not established.

They were written months apart, by different people, in subsystems that share no code. I only noticed they were one defect when the fourth one turned up.

Here is the shape.

A check confirmed that something was present. The result was reported as a claim that it worked.

Once you have the sentence, you start finding them everywhere.

The catalogue

A SIEM emitter that reported success without sending anything. The code fired four HTTP requests through setImmediate, attached .catch(() => undefined) to each, slept 800ms, and printed a green check. With no SIEM configured it printed the same green check, having made no request at all. Exit 0.

A coverage table that said a client was logging because it once had. Per-tool status read configured ✓ logged ✓. The second tick came from sessions > 0 — has this client ever recorded anything. One client had stopped capturing weeks earlier. The tick stayed green the entire time.

A doctor command that certified a launcher pointing nowhere. It checked whether a config contained something shaped like our entry. It did. The command that entry would run lived inside a temporary directory from an old test run — the kind the operating system clears on its own schedule. Configured, said the tool. Three clients were pinned to that throwaway install when we finally looked.

A signed-export flag that produced unsigned archives. --signed tried to sign, and when it couldn't — missing private key, more than one session selected — it caught the error, wrote the archive anyway, printed signed: no, and exited 0.

A verifier that passed those archives. Missing signature? A warning, then exit 0. Then we fixed that, and found that a signature file containing {} still passed, because the new check tested that the file could be read rather than that it contained a signature. Presence, reported as function, inside the fix for presence being reported as function.

An importer that made vendor exports look like first-hand observation. One import path recorded provenance metadata. The one beside it didn't. Records that came from a third-party export file were therefore indistinguishable, to every downstream reader, from sessions the tool had watched happen.

A summary that counted machine traffic as conversation. Turns were counted by role. A tool result is stored with role user — nobody typed it. A context-compaction marker is stored with role system — nobody said it. The code counted anything that wasn't user as AI, so both landed in the conversation totals.

Two implementations of one filter that disagreed. The table hid reviewed items by default. The JSON output didn't. A person and a script asking the same question got different answers, and only the script's was wrong.

The one that travels

These are not all equally bad, and the difference is worth naming.

A false "emitted" misleads the operator standing in front of the terminal. Annoying, recoverable, contained.

An unsigned archive from a --signed flag leaves the building. Someone receives a file whose name asserts that its origin can be established. They run the verifier. They get a zero. Nothing in that sequence tells them the archive proves nothing about where it came from.

Severity here isn't about how wrong the claim is. It's about how far the claim travels from the person able to check it.

So the fix wasn't "print a warning". It was: refuse. If --signed can't sign, it fails and writes nothing at the output path — because an unsigned file sitting where a --signed run was asked for is precisely what someone picks up later and trusts.

The one in our own pipeline

We fixed all of that. Then we released it, and the release workflow printed:

✓ Published chron-mcp@0.1.60 to npm

The registry 404'd for the version. For six minutes, the package did not exist.

npm publish returning 0 means the registry accepted the upload. npm says so itself, in output our own log captured: "Your package is being processed and may take a few minutes to become available." We printed our own success line immediately underneath it.

Worse: the step that syncs our public mirror ran next, and succeeded. For those six minutes the public repository advertised code that nobody could install.

Exit code, reported as availability. The same bug, in the pipeline that shipped the fixes for the same bug.

It now polls the registry until the version is present, the latest tag matches it, and a fresh install from the public registry reports the right version — then prints published. Three conditions, because any one alone can be true while the release is unusable.

The one I made while writing this up

I reported that npm had been 404ing "for about forty minutes."

It was six minutes and nine seconds. I had been comparing local timestamps against UTC ones and never did the subtraction. I filed the alarm sixteen seconds before the registry converged.

Forty minutes of silence from a package registry is an incident. Six is ordinary asynchronous propagation, which is what npm's output had said was happening all along. I'd spent two days removing unverified claims from a product and then made one, in the report about it, about a number I could have computed in one line.

The underlying finding was real. The evidence I gave for it was not.

What actually changed

Fixing twelve instances would have been worthless. What mattered was the structural changes:

Separate the three states, and only call one of them evidence. Our client diagnostics now report configured (an entry exists), loaded (for one client: not determinable from disk, and we say so), and captured (a session from this client is in the database, with when). Only the third is evidence, and only for the moment it happened.

Make the honest state reachable. Our delivery model had an unknown state for "sent, no trustworthy answer". It could never actually occur, because bare fetch has no timeout — a server that accepted a connection and never replied would hang forever. A state you cannot reach is not a state.

Let absence be the strong claim. A record saying something was read is the reading system's statement about itself. It establishes very little. The absence of such a record, when every read path emits reliably, is much harder to fake. Sell the negative; label the positive honestly.

Write refusals, not warnings. Every fix above replaced a warning with a non-zero exit. A warning is a claim that the caller will probably ignore. An exit code is one they have to handle.

Why the tests didn't catch any of it

This is the part I'd most want someone else to learn from.

Every layer was green independently. MCP connected. Tools available. Config exists. Database healthy. Tests passing.

The tests asserted our assumptions. They declared the expected configuration — including the stale launcher format — and so preserved the defect as a specification. They checked that a config entry existed, not that the process it named could start. They verified our tool list, not that the instructions were delivered. They ran inside workspaces that happened to contain a file whose absence was the actual failure mode.

The one test nobody had written:

fresh client → ordinary prompt → session appears in the database → both messages recorded

Everything else was infrastructure confirming its own existence.

The limit we had to publish

One more, because leaving it out would make this essay the thing it's about.

Our live capture depends on a model choosing to call a tool. We can deliver the instruction reliably. We cannot make a client obey it. During testing, one client hit a budget limit and stopped before logging; one refused the call under its default permission policy; one called the wrong tool entirely.

So the release ships saying so: capture is best-effort, not mandatory, and the diagnostics say configured where they used to say logging works. Enforcement needs an execution path we control — a wrapper that opens the audit session before the client starts and holds the output until the write lands — and we haven't built it.

Shipping a tool that declines to flatter its own integration is uncomfortable. It is less uncomfortable than the alternative, which is a green check mark that means nothing, in a product sold on its records being trustworthy.

If you build anything that reports on its own health, it's worth an afternoon with one question: for each green mark in your output, what did you actually observe, and when?

I expect you'll find at least one that answers "I observed that a thing exists, and I'm telling you it works."

One NUL byte made 14,994 signed records verify as tampered

Srinivas Kondepudi — Sat, 26 Sep 2026 19:06:42 +0000

I build Chron, a local audit log for AI coding sessions. Every message is hashed into a chain, so if a row is edited after the fact, verification fails and says which row.

Last week I added a path that imports existing Claude Code transcripts. I ran it against my own machine, 33 transcripts, about 70,000 events — and then, instead of spot-checking one session, verified all of them. The biggest one failed:

Verifying 3847fff0 — 14,994 messages
Hash chain
  ✗ Row 8842: content_hash mismatch — row tampered

Nothing had tampered with anything. The rows were minutes old and nothing but my own import had ever written them.

For a tool whose entire job is telling you whether a record was altered, a false positive is worse than a missed detection. A missed detection is a gap. A false positive teaches people to ignore the alarm.

What I assumed, and what it was

My first guess was ordering. Imported transcripts keep the client's line order rather than timestamp order, because 11,591 lines in my corpus carry a timestamp earlier than a line before them. Get that wrong and the chain links up in the wrong sequence.

That guess was wrong, and the error message said so. A prev_hash mismatch means the rows are in the wrong order. A content_hash mismatch means this row's stored hash doesn't match this row's stored fields. Ordering was fine. The row itself disagreed with itself.

Which shouldn't be possible. The code hashes a string and inserts the same string, in the same function, a few lines apart.

So I looked at what was actually in the row:

SELECT length(content)                  AS chars,
       length(cast(content AS blob))    AS bytes,
       instr(content, char(0))          AS nul_at
FROM messages WHERE id = '2d9746d3…';

chars  bytes  nul_at
298    530    299

298 characters. 530 bytes. And a NUL at position 299 — past the end of a string that is only 298 long.

The mechanism

SQLite stored every one of those 530 bytes. It is perfectly happy to hold a NUL inside a TEXT value. What it will not do is pretend the NUL isn't there when something asks for the value as a string. length() stops at the NUL. So does the driver, handing the value back to JavaScript.

wrote:  530 bytes
read:   298 characters, 308 bytes

So the write hashed 530 bytes of content and the verification hashed the 298 characters that came back. Two different inputs, two different digests, one "row tampered".

The content was tool output. Some program in some session printed a NUL byte, the way programs sometimes do, and it rode all the way into an evidence store. One byte, in one row, out of 73,526 — enough to invalidate a 14,994-event chain, because every row after it inherits the break.

The fix that doesn't work

The tempting fix is to strip the NUL inside the hash function. It fails, and it's worth seeing why:

Write: hash sanitize(content), store content — still 530 bytes, still with the NUL.
Verify: read back the truncated 298 characters, hash sanitize(truncated).

sanitize doesn't help, because the two sides aren't hashing the same content in the first place. The stored value is the problem. You have to change what goes into the database, not just what goes into the digest.

The rule I ended up writing on the wall: hash what you can read back. Not what you were handed — what the storage layer will give you again later.

Find out whether your stack does this

Rather than fix the one byte I'd found and move on, I went looking for what else wouldn't survive the trip. This is short enough to run against your own database:

import { createClient } from '@libsql/client';
import { createHash } from 'crypto';

const db = createClient({ url: 'file::memory:' });
await db.execute('CREATE TABLE t (id TEXT PRIMARY KEY, body TEXT)');

const sha = s => createHash('sha256').update(s).digest('hex').slice(0, 12);
const cases = {
  'embedded NUL':        `before${String.fromCharCode(0)}after`,
  'lone high surrogate': `before${String.fromCharCode(0xd800)}after`,
  'lone low surrogate':  `before${String.fromCharCode(0xdc00)}after`,
  'emoji (valid pair)':  'before\u{1f600}after',
  'CRLF and tab':        'before\r\n\tafter',
  'ESC and DEL':         `before${String.fromCharCode(0x1b)}${String.fromCharCode(0x7f)}after`,
};

for (const [name, wrote] of Object.entries(cases)) {
  await db.execute({ sql: 'INSERT INTO t VALUES (?, ?)', args: [name, wrote] });
  const read = (await db.execute({ sql: 'SELECT body FROM t WHERE id = ?', args: [name] })).rows[0].body;
  console.log(
    `${read === wrote ? 'ok    ' : 'BROKEN'} ${name.padEnd(20)} ` +
    `len ${wrote.length} -> ${read.length}  sha ${sha(wrote)} -> ${sha(read)}`
  );
}

On @libsql/client 0.17.3 and Node 23:

BROKEN embedded NUL         len 12 ->  6  sha 92e7bd379d66 -> 6db7d803e74f
BROKEN lone high surrogate  len 12 -> 12  sha a95d623c5792 -> a95d623c5792
BROKEN lone low surrogate   len 12 -> 12  sha a95d623c5792 -> a95d623c5792
ok     emoji (valid pair)   len 13 -> 13  sha cd9b426a0837 -> cd9b426a0837
ok     CRLF and tab         len 14 -> 14  sha 51daa3413452 -> 51daa3413452
ok     ESC and DEL          len 13 -> 13  sha 9cc6db066164 -> 9cc6db066164

Everything else I threw at it survives. Control characters are fine. CRLF is fine. Emoji are fine, as long as the surrogate pair is intact.

The near-miss in that output

Look at the two surrogate rows again. read === wrote is false — the string that came back is not the one that went in. But the hashes match.

I nearly wrote this up as "NUL and lone surrogates both break the chain." They don't, and the reason is more interesting than if they did.

A lone surrogate is not encodable as UTF-8. The driver substitutes U+FFFD on the way through. And Node's UTF-8 encoder performs the identical substitution when you hash the string:

Buffer.from('a\uD800b', 'utf8')  ->  61 ef bf bd 62
Buffer.from('a�b', 'utf8')  ->  61 ef bf bd 62

Both sides mangle it the same way, so the digests agree and verification passes. The integrity check survives on a coincidence, that two unrelated components happen to implement the same replacement rule.

Nothing documents that. Nothing enforces it. Hash bytes instead of a string, move to a runtime whose encoder throws instead of substituting, and the coincidence stops holding. A load-bearing accident is still an accident.

So I normalise both, for different reasons. The NUL, because it breaks verification today. The surrogate, because storing content the caller never sent is bad on its own terms, and because I would rather not depend on two encoders agreeing by luck.

Both become U+FFFD rather than being deleted. That's the standard marker for a character that couldn't be represented, and it keeps the fact that something was there.

Proving the test would have caught it

Writing a test after fixing a bug tells you nothing until you've watched it fail. I reverted the normalisation and ran the new tests against the old behaviour: 11 of 21 failed, including verification through every write path and a twelve-row chain. Put the fix back, all 21 pass.

That's the part I'd skip if I were in a hurry, and it's the part that tells you the test is real.

What I'd take from this

Hash what you can read back. Any scheme that hashes content and stores it separately has a serialisation boundary in the middle, and the boundary is allowed to change your data. Content-addressed stores, signed records, dedup keys, ETags - same shape, same exposure.

A silent substitution is worse than an error. Every layer here behaved reasonably on its own. SQLite stored the bytes. The driver returned a C string. Node's encoder replaced what it couldn't encode. Nothing logged a warning, and the defect surfaced as an accusation against innocent data.

Verify all of it, once. This was one row in 73,526. Any sampling strategy misses it. The only reason I found it before a user did is that I got suspicious and checked everything instead of the one session I'd picked.

And be careful which failures you claim. I was one draft away from publishing a confident, wrong explanation of the surrogate case. The probe was right there; I just hadn't read its output closely enough.

What Evidence Does an AI Agent Actually Need to Leave Behind?

Srinivas Kondepudi — Wed, 23 Sep 2026 09:28:39 +0000

What Evidence Does an AI Agent Actually Need to Leave Behind?

There is a question that keeps surfacing as AI agents move from answering questions in chat to actually doing things, writing code, modifying configs, calling APIs, deploying services.

The question is not "how do we stop them from acting?"

The question is: what evidence do we need after they act?

The Git Commit Problem

The reflex answer is: just look at the diff.

A Git commit shows you what changed. That used to be enough when a human sat behind every change. The human held the context. You could ask them. The commit message, however brief, was a pointer to a person who understood the decision.

With an AI agent, the commit is often the only artifact. And it hides almost everything that mattered:

What did the user actually ask for?
What did the agent read before deciding what to change?
Which tools did it call, and in what order?
Did it touch secrets, authentication tokens, environment variables, or production config along the way?
Was there a human in the loop, and if so, did they actually review anything, or just click Allow?
Can someone reconstruct the full sequence six months from now when something breaks in production?

A commit hash answers none of those questions.

Why This Is the Practical Governance Problem Right Now

We have spent years building approval workflows for human code changes. Pull requests, code review, change advisory boards, ticket numbers in commit messages. These processes assume a human author who can be questioned, who made a conscious decision, who can explain their reasoning.

AI agents break that assumption quietly.

The agent acts faster than review cycles were designed for. It calls ten tools in thirty seconds. It reads a config file, writes a new one, runs a test, opens a PR, and waits, all before anyone noticed it started. The change looks reasonable. The tests pass. The PR gets merged.

Three months later, something unexpected happens in production. You need to understand what the agent knew, what it read, what choices it made, and what a human approved.

If the only record is the commit, you have nothing.

The Minimum Viable Evidence Set

I am not arguing for heavyweight approval workflows on every AI action. That path leads to agents being so throttled they are useless.

But I do think every meaningful AI action, anything that modifies state outside the agent's own scratchpad, should leave enough evidence to answer questions when it matters.

Here is what that looks like in practice:

1. The original intent

What did the user ask for? Not the agent's interpretation, the actual message. This is the anchor for everything else. If the change cannot be traced back to a human request, that is itself meaningful information.

2. The tool call sequence

Which tools did the agent call, in what order, and what did it pass to them? This is the chain of decisions. A file read that preceded a file write tells you the agent saw the old value before replacing it. A secrets lookup before a config change is a different kind of event than a blind write.

3. What the agent read

Before an agent modifies something, it usually reads something. That read context is often the difference between "the agent made a reasonable change given what it saw" and "the agent made a change that only makes sense if it misread something."

4. Sensitive surface contact

Did the interaction touch authentication, authorization, secrets, infrastructure definitions, or production configuration? These are not just higher-risk changes, they are the category of changes that auditors, security teams, and incident responders will ask about first.

5. Human approval record

Was a human shown anything before the change happened? Did they click through a permission prompt, review a plan, or simply let the agent run autonomously? The presence or absence of human review is material. So is the kind of review, "I saw a one-line summary" is different from "I read the full plan and the diff."

6. Reconstructability

Can someone who was not in the room replay the sequence? Not re-run the agent, but follow the evidence trail and understand what happened. This is the test. If the answer is no, the evidence is insufficient.

Where People Draw the Line

In practice, teams end up in one of a few places:

Git history only. Fast, familiar, already required. Works fine when agents are doing what a junior developer would do and the stakes are low. Fails when something goes wrong and you need to explain the decision chain.

Tool-call logs. A step up. You know what the agent touched. You do not always know why, or what it read, or what the user originally asked for. Better for incident response than for governance.

Approval records. Some teams require a human sign-off checkpoint before the agent can modify certain surfaces — production, secrets, auth config. This is reasonable for high-stakes surfaces. It does not help you reconstruct what happened before the approval, or what the agent read to arrive at its proposal.

Full session traces. The full conversation, user messages, tool calls, reads, writes, tool results, stored with tamper-evident hashes. This is the complete evidence set. It is also the most expensive to store and the most sensitive to handle, because it may contain secrets that appeared in tool results.

The honest answer is that the right level depends on the surface. An agent writing unit tests probably does not need a full session trace. An agent modifying IAM policies probably does.

What Chron Is Doing Here

Chron is an MCP server that creates tamper-evident audit logs of AI sessions — stored locally, on your own machine, in a SQLite database you control.

Every tool call is logged with a cryptographic hash chain. The user's original message is captured. The sequence is reconstructable. The database does not leave your environment.

It crossed 9,000 npm downloads this week, which is a signal that the question this article is asking is not just theoretical. People are encountering it in real work and looking for answers.

Chron's position is deliberately minimal: it records, it does not certify. It does not tell you whether a change was authorized or correct. It gives you the evidence to answer those questions yourself, or to hand to someone else who needs to answer them later.

That boundary - recording vs. certifying - matters. The tool that captures evidence should not be the same tool that decides what the evidence means. Those are different jobs.

The Question Worth Asking Your Team

If an AI agent in your environment made a change right now, something it wrote, deployed, or modified, and three months from now you needed to explain that change to a customer, an auditor, or your own security team, what would you show them?

If the answer is "the commit," that is worth thinking about.

Not because commits are bad. Because they were designed for a world where a human sat behind every change, and that world is changing faster than our evidence practices are.

Chron is available as an MCP server: npx chron-mcp. It works with Claude, Cursor, and any MCP-compatible AI tool. The audit database is yours - local SQLite, no cloud egress.

The AI Race Has a Missing Question: Can We Explain What Our Agents Already Did?

Srinivas Kondepudi — Fri, 18 Sep 2026 16:08:34 +0000

The public conversation around advanced AI often collapses into two positions.

One side says we should slow down.

The other says progress is inevitable, so we should accelerate and compete.

Both arguments matter. But teams deploying AI agents today face a more immediate problem:

Can we explain what the agents already did inside our own environments?

That question is less dramatic than the future of superintelligence. It is also more operationally urgent.

AI coding assistants and autonomous agents are no longer limited to suggesting text in a chat window. They can inspect repositories, execute commands, call tools, modify files, use credentials, interact with ticketing systems, and reach external services.

Once that happens, "we have a policy" is no longer enough.

A team needs to be able to answer basic questions after an incident, review, or audit:

What was the original request?
Which tools did the agent use?
What happened between the prompt and the final answer?
Which files or systems were changed?
Was a risky action approved?
Did a person review the result?
Can someone else reconstruct the sequence later?

The important word is not logging. It is causality.

A repository might show that a file changed. A chat transcript might show that someone asked for help. An access log might show that a credential was used.

But those records often do not explain how the events connect:

Which agent action led to this command, which led to this file write, under which user request, with which approval?

That missing chain is where accountability disappears.

This is not an argument for blocking every action

Human checkpoints matter, especially for irreversible or high-impact actions. But prompting a person for approval on every operation creates its own failure mode: approval fatigue.

Anthropic has written publicly about this tradeoff. Its experience with agent permissions found that people approved the overwhelming majority of prompts, making constant confirmation an unreliable safety mechanism by itself. Their focus is increasingly on technical containment: constraining what an agent can do through boundaries such as sandboxes, virtual machines, and egress controls. Read How we contain Claude across products.

The point is not to eliminate human review.

It is to reserve it for the moments where it matters, then preserve evidence that the review happened.

Governance needs two layers

A useful operating model has two distinct layers.

Preventive controls constrain what an agent can do: scoped credentials, network boundaries, sandboxes, policy enforcement, and approval gates.

Detective controls preserve what the agent did: requests, tool calls, results, files changed, timestamps, decisions, approvals, and evidence of review.

One without the other is incomplete.

Preventive controls can reduce harm, but they cannot explain an action later unless the decision itself is recorded.

Logs can support an investigation, but they cannot prevent an agent from reaching a system it should never have been allowed to access.

This is why the conversation should not be "governance versus innovation." Good governance is part of what lets teams adopt useful agents with confidence.

OpenAI's own discussion of safely operating coding agents describes the same ingredients: technical boundaries, approval decisions, agent-aware telemetry, and the ability to inspect the original request, tool activity, results, and policy decisions when something needs review. Read Running Codex safely at OpenAI.

Build the evidence trail before you need it

The worst time to ask how an AI agent acted is after something went wrong.

By then, the prompt may be gone, the context may have been compacted, tool output may have changed, and the person who ran the session may not remember why a decision was made.

Evidence is cheap to preserve at the moment of action and expensive to reconstruct later.

That is the problem Chron is built around.

Chron is a local-first audit trail for AI-assisted work. It records AI sessions and their events, maintains evidence integrity locally, and helps teams find the sessions that warrant review. It does not certify compliance or replace a human auditor. It gives teams a more defensible starting point: a record of what occurred.

The argument about how quickly AI should progress will continue.

In the meantime, organizations should make sure that the AI already acting in their codebases and environments is not operating in a black box.

Because the question after an incident will not be:

"Was the model powerful?"

It will be:

"What did it do?"

Chron has passed 8,852 downloads. It is still early, local-first, and free to try:

npm install -g chron-mcp

The AI Race Is a Governance Problem Before It Is a Superintelligence Problem

Srinivas Kondepudi — Thu, 10 Sep 2026 09:13:56 +0000

The Long-Term Debate Is Already an Operational Problem

This week, a researcher who said he spent three years working at OpenAI and Anthropic resigned publicly and warned that leading labs are moving too quickly toward systems that may become difficult to control.

His warning is his own assessment, not a prediction anyone can prove today. But it raises a question that engineering teams should not wait to answer:

What evidence do we have of what our AI systems are actually doing?

From Answering Questions to Taking Actions

The long-term debate is about increasingly capable and autonomous systems.

The immediate problem is simpler.

AI tools already inspect repositories, execute commands, call tools, change files, and influence work in real environments. They are moving from "answering questions" to "taking actions."

When that happens, a prompt and a final answer are not enough.

The meaningful security and governance surface is everything in between:

the files an AI inspected
the tools it invoked
the commands it ran
the code it changed
the secrets it encountered
the actions a human reviewed or approved

That is not merely application logging. It is operational evidence.

The Gap: There Is No Default Evidence Trail

Most teams have some combination of chat history, source control, CI logs, and cloud audit logs.

Those are useful, but they are disconnected. They rarely answer one important question cleanly:

What did this AI-assisted task do, why did it do it, and can another person review the path afterward?

That gap matters today, even if you have no view on the most extreme forecasts about AI.

Organizations do not need to wait for hypothetical superintelligence before they make AI actions visible and reviewable.

What an Honest Evidence Trail Looks Like

A trustworthy record needs to be explicit about its boundaries.

If a tool did not observe part of a conversation, it should not recreate it from memory or ask the model to estimate what happened. That would turn self-report into evidence.

Chron v0.1.56 handles this with:

chron attach codex

The command begins recording an existing conversation from the current point onward. It marks the session as partial evidence and keeps the boundary visible in verification and coverage reports.

chron verify <session-id>
chron coverage

The message is deliberately plain:

Chron began recording after this conversation had already started. Earlier turns are outside the evidence boundary.

That is better than a complete-looking record with a hidden gap.

What Chron Is and Is Not

Chron is a local-first audit evidence layer for AI-assisted work. When configured with supported AI tools, it records messages, tool activity, code changes, secret detections, timestamps, and tamper-evident hashes.

It is not an alignment solution.

It is not a compliance certification.

It is not a substitute for human oversight.

It is one practical control: making AI-assisted actions inspectable after they happen.

Accountability Has to Start Somewhere

The AI race may be a global problem. But accountable evidence is something every engineering team can start building now.

npm install -g chron-mcp@latest

Chron is local-first and free to try. The public warnings from AI researchers are worth reading alongside the more practical lessons from real evaluation incidents — they are two sides of the same problem.

As AI gets more capable, "trust us" will not be enough. We need evidence.

My AI audit tool was merging Claude and Cursor sessions. The bug was one UNIQUE constraint.

Srinivas Kondepudi — Mon, 07 Sep 2026 18:12:25 +0000

I maintain Chron, an MCP server that writes an audit log of AI coding sessions to a local SQLite database. Every message gets a timestamp, and every session records which tool produced it: Claude, Cursor, Codex.

A while back I opened the history and found Claude messages and Cursor messages interleaved inside a single session. Two different tools, two different terminals, one session record.

For a tool whose entire job is attribution, that is about as bad as a bug gets.

The setup

The sessions table looked like this:

CREATE TABLE sessions (
  id       TEXT PRIMARY KEY,
  title    TEXT NOT NULL UNIQUE,
  ai_tool  TEXT,
  created_at TEXT NOT NULL,
  updated_at TEXT NOT NULL
);

When a tool starts work it calls init_session with a title and its own ai_tool. If a session with that title already exists, resume it. Otherwise create a new one.

Both Claude and Cursor generate a short descriptive title from the task. Working in the same repo on the same task, they generate the same title. Something like General assistance session.

UNIQUE(title) then guarantees only one row can exist for that title. So the second tool does not get its own session. It resumes the first one. Claude's messages and Cursor's messages land under the same session id, and ai_tool on that session reports whichever tool happened to start first.

The constraint was doing exactly what it was written to do. It was just the wrong constraint. A title was never the identity of a session. The pair (title, tool) was.

Fix attempt one, which does not work

The obvious move:

CREATE UNIQUE INDEX idx_sessions_title_tool ON sessions(title, ai_tool);

This is wrong, and it is wrong in a way that survives a casual test.

ai_tool is nullable. In SQL, NULL is never equal to NULL, and that includes comparisons inside a unique index. The constraint stops constraining the moment the column is NULL:

CREATE TABLE a (title TEXT NOT NULL, ai_tool TEXT);
CREATE UNIQUE INDEX ia ON a(title, ai_tool);

INSERT INTO a VALUES ('Session', NULL);
INSERT INTO a VALUES ('Session', NULL);   -- succeeds

SELECT count(*) FROM a;  -- 2

Two identical rows under a unique index. This is standard SQL behaviour rather than a SQLite quirk, but it is easy to forget the moment you add a nullable column to a composite key.

It mattered here because Chron has legitimate NULL ai_tool rows: sessions created through the library API without a tool set.

The fix

Index an expression instead of the raw column:

CREATE UNIQUE INDEX idx_sessions_title_tool
  ON sessions(title, COALESCE(ai_tool, ''));

NULL collapses to the empty string, which does compare equal to itself:

CREATE TABLE b (title TEXT NOT NULL, ai_tool TEXT);
CREATE UNIQUE INDEX ib ON b(title, COALESCE(ai_tool, ''));

INSERT INTO b VALUES ('Session', NULL);
INSERT INTO b VALUES ('Session', NULL);      -- UNIQUE constraint failed
INSERT INTO b VALUES ('Session', 'claude');  -- ok
INSERT INTO b VALUES ('Session', 'cursor');  -- ok

One row per tool, duplicates within a tool still rejected. That is the property I actually wanted.

The lookup code had to match, of course. Resume was searching by title alone, so even with the right constraint it would have kept finding the other tool's row:

// before
const existing = await db.select().from(sessions)
  .where(eq(sessions.title, args.title));

// after
const existing = await db.select().from(sessions)
  .where(and(
    eq(sessions.title, args.title),
    requestedTool === null
      ? isNull(sessions.ai_tool)
      : eq(sessions.ai_tool, requestedTool),
  ));

A constraint and the query that relies on it are one unit. Changing only one of them just moves the bug.

Dropping a constraint in SQLite

SQLite has no ALTER TABLE ... DROP CONSTRAINT. The inline UNIQUE on title is part of the table definition, so removing it means rebuilding the table:

await client.execute('PRAGMA foreign_keys = OFF');
await client.execute('BEGIN');
try {
  await client.execute(`CREATE TABLE sessions_migration (
    id TEXT PRIMARY KEY,
    title TEXT NOT NULL,     -- no UNIQUE
    ai_tool TEXT,
    ...
  )`);
  await client.execute(
    'INSERT INTO sessions_migration SELECT id,title,ai_tool,... FROM sessions'
  );
  await client.execute('DROP TABLE sessions');
  await client.execute('ALTER TABLE sessions_migration RENAME TO sessions');
  await client.execute('COMMIT');
} catch (e) {
  try { await client.execute('ROLLBACK'); } catch { /* ignore */ }
  throw e;
} finally {
  await client.execute('PRAGMA foreign_keys = ON');
}

Standard shadow-table dance. Nothing surprising.

The migration bug that was worse than the original bug

Here is the part worth the post.

I first wrote the migration guard as: if the composite index does not exist, migrate. It reads perfectly sensibly, and it fails on exactly the databases that need it.

The schema bootstrap runs CREATE UNIQUE INDEX IF NOT EXISTS idx_sessions_title_tool ... before the migration check. On an existing database that still carries the legacy inline UNIQUE(title), that statement succeeds. It creates the composite index on the old table. The old constraint is still sitting there, untouched.

So by the time the migration check runs, the index exists, the guard concludes "already migrated", and it skips. The table keeps UNIQUE(title) forever.

Fresh databases were fine, because they were created correctly from the start. The test suite passed, because tests build fresh databases. Every real user upgrading from an older version would have kept the bug.

The guard has to ask about the constraint, not about a side effect that usually correlates with it. The only way to see the constraint is the stored DDL:

const info = await client.execute(
  "SELECT sql FROM sqlite_master WHERE type='table' AND name='sessions'"
);
const tableSql = String(info.rows[0]?.sql ?? '');
const hasLegacyTitleUnique =
  /\btitle\s+TEXT\s+NOT\s+NULL\s+UNIQUE\b/i.test(tableSql);

if (hasLegacyTitleUnique || compositeIdxMissing) {
  // rebuild
}

Regex against DDL is not elegant. It is, however, the thing that is actually true.

And the test has to start from the old schema, not a fresh one:

// build a legacy database on purpose
await client.execute(`CREATE TABLE sessions (
  id TEXT PRIMARY KEY,
  title TEXT NOT NULL UNIQUE,   -- the old constraint
  ai_tool TEXT, ...
)`);
await client.execute(`INSERT INTO sessions VALUES ('old-claude', 'General assistance session', 'claude', ...)`);

await initDb(dbPath);

const table = await client.execute(
  "SELECT sql FROM sqlite_master WHERE type='table' AND name='sessions'"
);
expect(String(table.rows[0].sql)).not.toMatch(/\btitle\s+TEXT\s+NOT\s+NULL\s+UNIQUE\b/i);

// cursor can now hold the same title
await client.execute(`INSERT INTO sessions VALUES ('new-cursor', 'General assistance session', 'cursor', ...)`);

// but a duplicate within the same tool is still rejected
await expect(client.execute(
  `INSERT INTO sessions VALUES ('dupe-claude', 'General assistance session', 'claude', ...)`
)).rejects.toThrow();

What I took from this

A UNIQUE constraint is an identity claim. UNIQUE(title) asserted "a title identifies a session". That was never true, and the database enforced the false claim faithfully until the day two tools showed up.

Nullable columns in composite unique indexes usually do not do what you want. If the column can be NULL, index an expression.

Migration guards should test for the thing you are fixing. Not for a marker that normally accompanies it. Ordering inside your own bootstrap can invalidate the marker.

A migration test that starts from a fresh schema tests nothing. Construct the old schema, put a row in it, then migrate. This is the one that nearly got me: the fix was correct, the suite was green, and real upgrades would have stayed broken.

That last point is the general shape of the lesson. Green tests told me the bug was fixed. They were testing a database that never had the bug.

Chron is on npm as chron-mcp if you want to look at the code, or run npx chron-mcp to point it at your own AI sessions.

npm Trusted Publishing fails with a 404, and the 404 is lying to you

Srinivas Kondepudi — Sun, 06 Sep 2026 14:43:49 +0000

npm is winding down 2FA-bypass granular access tokens. Since 31 July 2026 they can no longer perform account, organisation, or package management operations, which includes editing trusted publishing configuration. In January 2027 they lose direct publish as well, leaving them able to read private packages and stage a publish that a maintainer then approves with 2FA.

The replacement is OIDC Trusted Publishing, where you register a GitHub repo and workflow on npmjs.com and the workflow authenticates with a short-lived token instead of a stored secret.

I migrated. The release workflow then failed four times in a row, and the error message pointed nowhere near the actual problem.

This is the writeup I wanted to find while debugging it.

The symptom

npm notice publish Signed provenance statement with source and
  build information from GitHub Actions
npm notice publish Provenance statement published to transparency log:
  https://search.sigstore.dev/?logIndex=2685306213
npm error code E404
npm error 404 Not Found - PUT https://registry.npmjs.org/chron-mcp - Not found
npm error 404  'chron-mcp@0.1.55' is not in this registry.

The package exists. It has published versions. I own it. And the registry says it is not there.

Two things in that output are actively misleading, and I chased both.

Red herring one: the provenance step succeeds

Look at the order. Provenance signing works. It reaches sigstore, signs, and posts to the public transparency log. That requires the GitHub Actions OIDC token, so id-token: write is clearly working.

It is very natural to conclude that OIDC is fine and the problem is something else.

It is not the same feature. Provenance signing uses the OIDC id-token to sign an attestation with sigstore. Trusted Publishing uses the OIDC id-token to exchange for a registry auth token. Different mechanisms, different code paths, introduced in different npm versions. One can work perfectly while the other does not exist.

Red herring two: a token that looks leaked

The step environment shows this:

env:
  NPM_CONFIG_USERCONFIG: /home/runner/work/_temp/.npmrc
  NODE_AUTH_TOKEN: XXXXX-XXXXX-XXXXX-XXXXX

That looks like a masked secret. My first theory was that a stale NPM_TOKEN was being injected and overriding OIDC, so I removed it from the workflow and added unset NODE_AUTH_TOKEN.

It made no difference, because that value is not a secret at all. GitHub is not masking anything. Those are real X characters.

actions/setup-node@v4 writes an .npmrc containing //registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}, and then exports a dummy value when you have not supplied one, so that npm does not warn about a missing variable. From src/authutil.ts on the v4 tag:

// Export empty node_auth_token if didn't exist so npm doesn't complain
// about not being able to find it
core.exportVariable(
  'NODE_AUTH_TOKEN',
  process.env.NODE_AUTH_TOKEN || 'XXXXX-XXXXX-XXXXX-XXXXX'
);

Worth knowing that this is version-specific. On main the action has changed to only export the variable when the user actually provided one, so if you are on a newer major you may not see this at all. If you are pinned to v4, you will, and it looks exactly like a leaked credential.

For completeness, a pre-set token would not block OIDC anyway. In lib/commands/publish.js, oidc() is called before credentials are read, and it overwrites the auth token directly:

await oidc({ packageName: manifest.name, registry, opts, config: this.npm.config })

const creds = this.npm.config.getCredentialsByURI(registry)

The actual cause

The workflow pinned Node 20:

- uses: actions/setup-node@v4
  with:
    node-version: 20

Node 20 bundles npm 10.8.2. npm documents the requirement as npm CLI 11.5.1 or later, and Node 22.14.0 or higher.

npm 10 does not have a partial or broken implementation. It has none at all. You can verify this without reading a changelog:

for v in 10.8.2 11.5.0 11.5.1 11.19.0; do
  npm pack npm@$v --silent >/dev/null
  mkdir -p ex-$v && tar xzf npm-$v.tgz -C ex-$v
  echo "npm $v -> $(ls ex-$v/package/lib/utils/oidc.js 2>/dev/null || echo 'NO OIDC')"
done

npm 10.8.2  -> NO OIDC
npm 11.5.0  -> ex-11.5.0/package/lib/utils/oidc.js
npm 11.5.1  -> ex-11.5.1/package/lib/utils/oidc.js
npm 11.19.0 -> ex-11.19.0/package/lib/utils/oidc.js

So npm 10 never attempts the token exchange. It falls back to the _authToken in the generated .npmrc, which resolves to nothing useful, and publishes unauthenticated.

You will notice 11.5.0 has the file too, which is worth explaining rather than glossing over. The OIDC code first shipped in 11.5.0, and the only difference in 11.5.1 is a scoping fix in the same file:

-      let enableProvenance = false     // declared inside the inner block
+    let enableProvenance = false       // hoisted out

In 11.5.0 the provenance-enabling branch sat inside an inner block, so it could not fire correctly. The token exchange itself is byte-identical between the two. That is why npm's documented floor is 11.5.1 rather than 11.5.0, and it is the version to pin. The distinction does not matter for the 404 in this post, because Node 20 gives you npm 10, which has nothing at all.

Why an unauthenticated publish returns 404

This is the part that wasted the most time.

The publish went out with no usable credential at all, and the registry answered 404 rather than 401 or 403. The explanation usually given is that answering 403 would confirm a package exists, letting anyone enumerate private package names by guessing, so the registry collapses "does not exist" and "you may not see this" into one response. I have not found npm stating that intent in those words, so take the reasoning as the community explanation and the behaviour as the observed fact.

The distinction that actually helps you debug is this one:

403 usually means your credential arrived and the identity behind it is not allowed to publish this package. The familiar form is You do not have permission to publish "x". Are you logged in as the correct user?
404 on a package you own usually means the registry never established who you are at all. The credential is missing, empty, or never sent.

So read 'chron-mcp@0.1.55' is not in this registry as a statement about your identity, not about your package name. That is the most useful reframing in this post. I spent a long time re-checking the package name, the scope, and the registry URL, when the message was really telling me the request was anonymous.

The fix, part one

- uses: actions/setup-node@v4
  with:
    node-version: 24
    registry-url: https://registry.npmjs.org

- name: Ensure npm supports OIDC trusted publishing
  run: |
    npm install -g npm@^11.5.1
    npm --version

Node 24 bundles npm 11.19.0, which is already sufficient. The explicit global install is a guard: Node 24.0.0 shipped npm 11.3.0, which is below the threshold, so pinning the major alone is not a guarantee. Printing npm --version into the log means the next person to debug this can rule it out in one glance.

The fix, part two, which the first fix revealed

With authentication working, the error changed. That is progress, even when it is still red:

npm error code E422
npm error 422 Unprocessable Entity - PUT https://registry.npmjs.org/chron-mcp -
  Error verifying sigstore provenance bundle: Unsupported GitHub Actions source
  repository visibility: "private". Only public source repositories are
  supported when publishing with provenance.

Provenance requires a public source repository. The repo publishing this package is private, so provenance was never achievable, and --provenance had been wrong from the first commit. It stayed invisible because the auth failure happened first.

The fix is to drop the flag rather than to add --no-provenance. From lib/utils/oidc.js:

const isDefaultProvenance = config.isDefault('provenance')
if (isDefaultProvenance && !ciInfo.CIRCLE) {
  const payload = JSON.parse(/* decoded id-token */)
  if (ciInfo.GITHUB_ACTIONS && payload.repository_visibility === 'public') {
    const visibility = await libaccess.getVisibility(packageName, opts)
    if (visibility?.public) {
      opts.provenance = true
    }
  }
}

npm auto-enables provenance only when the flag was left at its default and repository_visibility is "public". Passing --provenance explicitly sets isDefault to false and forces it on regardless. Omitting it lets npm make the correct decision on its own.

-  npm publish --access public --provenance --ignore-scripts
+  npm publish --access public --ignore-scripts

Green on the next run.

The working workflow

permissions:
  contents: read
  id-token: write     # required for OIDC

steps:
  - uses: actions/checkout@v4

  - uses: actions/setup-node@v4
    with:
      node-version: 24
      registry-url: https://registry.npmjs.org

  - name: Ensure npm supports OIDC trusted publishing
    run: |
      npm install -g npm@^11.5.1
      npm --version

  - run: npm ci
  - run: npm test

  - name: Publish
    run: npm publish --access public --ignore-scripts

No NODE_AUTH_TOKEN. No NPM_TOKEN secret. The Trusted Publisher is configured on npmjs.com under the package's Settings, pointing at the repo and the workflow filename, and both have to match exactly.

Checklist if you hit this

Print npm --version in the job. npm 10 and below will not attempt OIDC at all, and 11.5.1 is npm's documented floor. This is the single highest-value check and it takes one line.
Read a 404 on a package you own as an identity problem, not a naming one. A 403 usually means your credential arrived and was rejected; a 404 usually means it was never established.
Do not treat a successful provenance step as proof that auth works. They are separate features.
NODE_AUTH_TOKEN: XXXXX-XXXXX-XXXXX-XXXXX is a literal placeholder, not a masked secret.
Only use --provenance if the source repo is public. Otherwise omit it and let npm decide.
Check the Trusted Publisher's workflow filename matches the workflow that actually runs the publish.

The general lesson is about error messages that withhold information. The 404 was not a bug. It was the registry saying it did not know who I was, in the least specific way available to it, and I read it literally for far longer than I should have.