HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
ctxrs
ctx
Rust2026–2026
ctxrs / ctx

ctx

Instant recall for coding agents. Search the history already on your machine. Git blame, but for agent sessions.

6Distinct people
10Mentions
0Explicit recommenders
1.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Instant recall for coding agents. Search the history already on your machine. Git blame, but for agent sessions.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by week10 dated mentions

Observed mentions: 2026-04-03 14:54:32 UTC to 2026-09-03 14:09:53 UTC. Weeks start Monday, UTC.

01232026-03-30 00:00:00 UTC to 2026-04-06 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 commentsMar 302026-04-06 00:00:00 UTC to 2026-04-13 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-13 00:00:00 UTC to 2026-04-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-20 00:00:00 UTC to 2026-04-27 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-04-27 00:00:00 UTC to 2026-05-04 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-05-04 00:00:00 UTC to 2026-05-11 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-05-11 00:00:00 UTC to 2026-05-18 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-05-18 00:00:00 UTC to 2026-05-25 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-05-25 00:00:00 UTC to 2026-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-01 00:00:00 UTC to 2026-06-08 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-08 00:00:00 UTC to 2026-06-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-15 00:00:00 UTC to 2026-06-22 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 commentsJun 152026-06-22 00:00:00 UTC to 2026-06-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-29 00:00:00 UTC to 2026-07-06 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2026-07-06 00:00:00 UTC to 2026-07-13 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-07-13 00:00:00 UTC to 2026-07-20 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-07-20 00:00:00 UTC to 2026-07-27 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-07-27 00:00:00 UTC to 2026-08-03 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-08-03 00:00:00 UTC to 2026-08-10 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-08-10 00:00:00 UTC to 2026-08-17 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-08-17 00:00:00 UTC to 2026-08-24 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2026-08-24 00:00:00 UTC to 2026-08-31 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-08-31 00:00:00 UTC to 2026-09-07 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsAug 31

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Mar 302026-03-30 00:00:00 UTC2026-04-06 00:00:00 UTC202
Apr 62026-04-06 00:00:00 UTC2026-04-13 00:00:00 UTC000
Apr 132026-04-13 00:00:00 UTC2026-04-20 00:00:00 UTC000
Apr 202026-04-20 00:00:00 UTC2026-04-27 00:00:00 UTC000
Apr 272026-04-27 00:00:00 UTC2026-05-04 00:00:00 UTC000
May 42026-05-04 00:00:00 UTC2026-05-11 00:00:00 UTC000
May 112026-05-11 00:00:00 UTC2026-05-18 00:00:00 UTC000
May 182026-05-18 00:00:00 UTC2026-05-25 00:00:00 UTC000
May 252026-05-25 00:00:00 UTC2026-06-01 00:00:00 UTC000
Jun 12026-06-01 00:00:00 UTC2026-06-08 00:00:00 UTC000
Jun 82026-06-08 00:00:00 UTC2026-06-15 00:00:00 UTC000
Jun 152026-06-15 00:00:00 UTC2026-06-22 00:00:00 UTC321
Jun 222026-06-22 00:00:00 UTC2026-06-29 00:00:00 UTC000
Jun 292026-06-29 00:00:00 UTC2026-07-06 00:00:00 UTC211
Jul 62026-07-06 00:00:00 UTC2026-07-13 00:00:00 UTC000
Jul 132026-07-13 00:00:00 UTC2026-07-20 00:00:00 UTC101
Jul 202026-07-20 00:00:00 UTC2026-07-27 00:00:00 UTC000
Jul 272026-07-27 00:00:00 UTC2026-08-03 00:00:00 UTC000
Aug 32026-08-03 00:00:00 UTC2026-08-10 00:00:00 UTC000
Aug 102026-08-10 00:00:00 UTC2026-08-17 00:00:00 UTC000
Aug 172026-08-17 00:00:00 UTC2026-08-24 00:00:00 UTC110
Aug 242026-08-24 00:00:00 UTC2026-08-31 00:00:00 UTC000
Aug 312026-08-31 00:00:00 UTC2026-09-07 00:00:00 UTC110

What Hacker News says

10 sources
luca-ctx·Sep 3, 2026Submission

Show HN: Instantly get the transcript from the agent that wrote any line of code

This is basically "git blame but for agent sessions". In the olden days, we would use git blame (or gitlens extension) to see what body of work a certain line range or file was a part of. We would look back at the PR to see why something was done a certain way. While agents can still do this part well, we can now take it a step further: we can surface the entire agent session from when the code was originally committed! You (or rather your agent) can go back and read the entire original transcript from when it was done. This is very helpful for figuring out why something was done wrong. Maybe a missed assumption, maybe just regular slop. Either way it helps a ton to reference the original implementation session. This is an extra capability, you can also use the regular search to pull up old sessions and work. It runs fully locally and has
Read the rest
a pretty cool set of performance optimizations if you care to look into what makes it so fast. I built it for myself and didn't look at my own usage levels until this week and realized the search and blame commands are being used over 1k times per day (yes it's a lot, but against 5b tokens per day it's reasonable).
5 points · Open discussion
Hi HN. I built deja after watching Claude Code and Codex debug the same problems more than once. The annoying thing was that the answer usually already existed somewhere in my old sessions. My records were stored on the disk for months (~3.3 GB). It wasn't easy to find them manually and the new agent session had no idea what the other agent had already found out. deja indexes the transcripts that Claude Code, Codex, and opencode already write. On my corpus, the initial index takes about 10 seconds and warm searches are 7-9 ms. There are 3 ways to get the memory back: a normal CLI search, an MCP tool (agent can query it directly) and a SessionStart hook that automatically injects a bit of relevant project context. The feature I built this for: deja sync ssh <host> It moves new memory between machines using the existing SSH setup. Secret da
Read the rest
ta is deleted during indexing and checked again before exporting. My setup is a laptop and a mac mini without an interface. The agent can work on the mini all night, and in the morning I extract its memory. Then the agent on my laptop will know what the mini tried, what broke, and what eventually worked. There are other projects (cass, ctx, claude-mem): https://github.com/Dicklesworthstone/coding_agent_session_se... https://github.com/ctxrs/ctx https://github.com/thedotmack/claude-mem I wanted deja to intentionally use a small approach: one binary code with zero dependency, no LLM calls, searchable verbatim text instead of generated summaries, and synchronization via your own SSH. It does not implement its own network transport; it just connects to the system ssh/scp. You can install it via curl, brew, npx or go install, then run: deja install --all
In Open-source memory for coding agents, synced over SSH
luca-ctx·Jul 2, 2026Submission

Show HN: ctx – Search the coding agent history already on your machine

Coding agents don't have long-term memory. But you do have months of full-fidelity agent transcripts stored on your machine. A simple solution that goes a long way: ingest those transcripts and logs into a structured SQLite database, then search them with ranked text match. Everything is fully local and doesn't require anything fancy like a graph database or hosted memory service. This is the idea behind ctx, a Rust CLI that handles the ingestion and searching. We give our agents a skill that tells them to reference past sessions before working in an area. Usually we do this through an "Agent History Research Subagent" whose job is just to prepare a short brief covering any relevant history before the task begins. A real example: sometimes our test suite runs would fail because disk was full on the runner. The correct approach was to run
Read the rest
the cleanup runbook, but the root cause of the failure was not clear to the agents, so they would think it was a test regression and go down the wrong rabbit hole debugging. When the agent searched history, it realized this failure had been encountered before and found the right workaround immediately. That got the agent onto the right cleanup path, and later we improved the log output so the same failure would be clearer next time. It's a boring story, but it's real agent productivity. Another nice use case is quickly generating session transcripts for sharing. You can exclude the noisy intermediate messages, so the transcript shows the important parts of the session more cleanly. Try attaching a session transcript to your next PR so your teammate and their agent can review the provenance and prompting behind the change. If you're up for an additional challenge, ask your agent to "exhaustively review all agent history in this repo and find where the SDLC is struggling or isn't agent-native". Using past sessions to recursively improve the agentic SDLC is a loop that we're using a lot today. If you try it out, please let us know what you think!
65 points · Open discussion
Hi HN, OP here. We posted here back in April and the most common request was to make the source code public. As of today, ctx is now open-source: https://github.com/ctxrs/ctx ctx is an Agentic Development Environment (ADE), similar to the Codex desktop app, but it works with any agent harness. I wrote more about why we are open sourcing it here: https://ctx.rs/blog/open-sourcing-ctx A few things contributed to the decision to do this: - We fell in love with Pi's extensibility model. In late 2025, we were forking Codex to add and change behaviors, but even small changes required deep surgery and rebuilding. Lately, we've been able to make those same changes with Pi, but it's so much easier. It feels closer to configuring a tool rather than rebuilding its internals. Everything seems to "just work" as an extension/plugin. We realized we want
Read the rest
ed our ADE to work like that too. You should be able to have a sensible default desktop app, and then powerful customization options to change how it looks and works. - The AI ecosystem is rapidly coalescing into a state-adjacent oligopoly. Today, SpaceX announced it will acquire Cursor, and last week the US government shut down Fable/Mythos. This trend is not new, but it has been accelerating lately. It makes the case for an open agent tooling ecosystem much more compelling. - We realized we cannot build the one perfect ADE for everyone. No amount of predetermined customization options can support the near-infinite creativity that is possible through open source code. This is especially true when everyone has a coding agent that can quickly implement customization on the fly. Maybe this is "Software 3.0" finally starting to show itself. From here, the roadmap is to make ctx more hackable. Right now it is a fairly involved Rust daemon plus desktop app. It's performant, but customization still requires cloning the repo, changing code, and rebuilding. We want to move toward a Pi-like model with extensions, plugins, and hot-reloading, while keeping the core runtime in Rust. We'd also like to accelerate development of the mobile app (via a bring-your-own tunnel like ngrok, or hosted tunnel) as well as support for Windows (it is Mac and Linux only right now). Happy to answer any questions about it.
In ctx, a hackable desktop workbench for coding agents, is now open source

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.