Get started
KurrentDB

From recorded sessions
to shared memory

Capture the work behind your code, understand what happened, and give the next session a place to start

Capture locally
Connect the work

Hooks and transcript watchers send recorded activity to the server. Agents query session history through MCP.

The server stores the event stream in KurrentDB

This shows a shared workspace. The Local plan keeps the session record on your machine.

Shared workspace architectureOn Your machine, you interact with the coding agent and CLI. Agent hooks send events to the server; the watcher sends transcript activity. Agents query the server through MCP. The CLI also connects to the server, which reads and writes the KurrentDB event store. Your machine Your shared workspace Coding agent · Claude Code, Codex, … kcap hooks agent transcript kcap CLI kcap MCP server kcap watcher kcap server Session event store (KurrentDB) You tool calls hook events live transcript

On your machine

Hooks and a background watcher capture activity from the coding agents you choose

kcap status
Server
northwind.kcap.ai ✓
Hooks
Claude ✓ Codex ✓ Cursor ✓
Daemon
running

In your workspace

For a shared workspace, recorded sessions reach your team’s server, ready to browse, search and recall

Pick up where you left off 3All
Rate-limit the public export endpointlive · claude-code · northwind/payments · started 38m agoMigrate Stripe SDK to v17live · codex · northwind/payments · started 1h 12m agoFix hydration mismatch on the cart drawerlive · cursor · northwind/checkout · started 2h ago
01

Record the work

Capture new sessions as you work, or import available history from supported agents

kcap import --all
[claude] Loaded 171 · Resumed 3
[codex] Loaded 40
214 imported · 0 failed
02

Keep the history

Recorded prompts, tool calls and results become an event stream you can inspect alongside the final diff

Recorded events
  1. Session Summary Computed186 tool calls · 2 errors
  2. Session Endedexit
  3. Assistant Text GeneratedOpened PR #1279: TokenCache takes an injectable clock
  4. Open the pull request1.9k → 96 (Σ 2k)
  5. Run the auth suite 50×2.4k → 88 (Σ 2.5k)
  6. Review the diff before the PRcode-reviewer · 1.2k → 310 (Σ 1.5k)
  7. Edit test/auth/token-cache.test.ts+61 −4 · 2.2k → 1.4k (Σ 3.6k)
  8. Edit src/auth/refresh.ts+9 −11 · 1.8k → 420 (Σ 2.2k)
  9. Edit src/auth/token-cache.ts+48 −21 · 2.6k → 980 (Σ 3.6k)
  10. Edit src/auth/clock.ts+22 · 1.1k → 540 (Σ 1.6k)
  11. User Message ReceivedClock injection looks right. Go ahead, keep the public API of TokenCache.
  12. Assistant Text Generated7 of 50 runs fail. The cause is in TTL
  13. Grep 4 matchesDate.now() in src/auth
  14. Find every caller of TokenCacheExplore · 980 → 260 (Σ 1.2k)
  15. Run the refresh test 50×2.1k → 180 (Σ 2.3k)
03

Understand the outcome

See what changed, what was tried and what the agent reported testing. Follow the record when you need the evidence.

Outcome

Root cause: TokenCache derived its TTL from expires_in without subtracting the 30s refresh skew. On slow CI runners the clock crossed expiry between refresh check and request, so roughly 1 in 7 runs failed.

  • Tried jest.useFakeTimers first—abandoned after 12 minutes: refresh() read Date.now() directly, so the race persisted.
  • Injected a Clock into TokenCache; TTL now expires_in − skew.
  • Added a regression test that advances the clock to 1 ms before the skew boundary.
  • Ran the auth suite 50× locally: 0 failures (7 of 50 before the fix). Opened PR #1279.
04

Recall it next time

Your agent can search sessions you have access to, so earlier decisions don’t have to be rediscovered

Have we worked on this before?
kcap-sessions · search_sessions

Yes: Tomás fixed it in PR #1279.

The session records the TTL issue, the clock-injection fix and the reported test results

Start with your next session

Request an invite