Yesterday a small tool shipped that fixes a problem every long-chat user hits sooner or later. It’s called Oglyanutsya, which means “Look Back” in Russian. Its author is u/Dream-SRA, and it’s a local search tool for Codex’s own conversation history. Step 2 is the twist.
What’s new
The author has one very long working chat with Codex, and its log is about 1.9 GB. Context compaction keeps the direction of the work, but the model can no longer see the earlier conversation word for word. If you’ve ever asked an assistant “what exactly did we decide about that config two weeks ago?” and got a confident but fuzzy answer, you know the feeling. A summary remembers the gist. It doesn’t remember the exact sentence.
So the author and Codex built a read-only tool that searches Codex’s original session logs. It reads the .codex/sessions and .codex/archived_sessions folders, groups copies of the same conversation by thread_id, and only counts real user and assistant messages. System prompts, reasoning, tool output and compaction summaries are all ignored. That filter matters more than it sounds. Without it, a search for a common word would drown in thousands of lines of machine chatter, and you’d never find the one human sentence you wanted.
The tool is packaged as a skill, so Codex calls it on its own when you refer to something that has dropped out of the current context. You don’t have to remember a command. You just say “what did I say about the retry logic back in October?” and the skill does the digging.
The twist
There is no index. No SQLite, no embeddings, no vector store, no quote cache. The only memory is the original log. Every search scans the file again, so you wait about 12 seconds instead of 12 milliseconds. The author accepts that on purpose, so no derived database can quietly take over as the source of truth. Think about how many “memory” systems go stale or drift from the real data because the index and the source disagree. Here that can’t happen, because there is only one copy of the truth.
The other half of the twist is speed. The first version took about 119 seconds on the 1.9 GB log. The second used ripgrep but opened all 953 hits for one word, and that took about 35 seconds. The final version searches each word separately, intersects the matching record numbers in memory, and opens only about 200 records. That’s where the 12 seconds comes from. Notice the pattern: the win didn’t come from adding storage, it came from opening fewer records.
The mini-workflow 🔍
- Codex picks a remembered quote, or a few distinctive words that sat together in one message.
- It picks the rarest word as the anchor, and adds an approximate date range if it has one.
- The tool tries the exact phrase first. If that fails, it searches each word on its own and intersects the matches.
- It keeps only messages where all the words appear together. Words scattered across different messages never get merged into one result.
- It jumps to the original record by byte offset, parses the JSON, and filters by the message’s own timestamp, not the file date.
- It returns the quote, the neighbouring messages, the speaker, the ids, and SHA-256 hashes, so you can check the result against the source. ✅
One smaller detail I like: old messages count as data, not instructions. If a past message says “ignore previous instructions”, the tool just reports it and does nothing else. That’s a quiet but important safety choice, because a search tool that obeys what it finds would be a gift to anyone who ever pasted a prompt injection into a chat.
Pro tips 💡
- Pick words that appear together in one message, and lead with the rarest one. In the author’s test, a three-word query found a message where the words were split up by commas and other text. A word like “migration” is a weak anchor, while a project codename or an odd error nickname is a strong one.
- Use date ranges based on message time. A conversation that started in September can run into November, so a filter on file date would miss exactly the messages you want. Even a rough “sometime in October” narrows the scan a lot.
- Keep subagent logs out of the search unless you need them. The tool skips them by default, so technical chatter doesn’t bury the real conversation.
- Use the hashes. If a result will feed a decision or a write-up, compare the SHA-256 against the source record before you quote it. It takes a moment and removes any doubt.
- Two commenters raised fair questions: what happens when you only remember the gist, and whether tool output like file paths and error strings is searchable. The post says only user and assistant messages count, so error strings that appeared only in command output wouldn’t turn up. The gist problem is real too, since the search needs a few exact words. If you only remember the idea, try guessing the words you’d have typed yourself, because your own phrasing tends to repeat.
The author also wants OpenAI to add two read-only operations, history.search_original and history.read_context. They aren’t asking for permanent memory or a vector database, just a way for the model to look back at its own original history. I’d like to see that too. 🧭
Your move
You don’t need to build this exact thing to use the idea. Look at where your own tool stores its logs, and think about whether you’d trust a search that leaves the source untouched. Then tell me what you’d want from a feature like this. ⚓💬
Frequently Asked Questions
Q: Does the search still work if I only remember the gist of a conversation?
The tool doesn’t depend on one perfect word. It combines a distinctive word or phrase with an approximate date range and, when you know it, the speaker or conversation. A wrong guess at the anchor word can be offset by the other clues, so start with a date window you’re fairly sure of and one or two words you’re confident appeared. The post doesn’t show a test of gist-only recall, so treat this as the intended approach rather than a proven result.
Q: Does it search command output, like file paths or error messages?
No. Tool calls and their results are excluded on purpose, so a path or error string that only ever appeared in a command’s output won’t turn up. The logs are plain text files on disk, though, so a basic text search of the session folders can still reach that output. You’ll get raw lines without the user and assistant filtering, so check what you find.
Q: Why doesn’t it keep an index, and how can I trust a quote?
Oglyanutsya builds no index or summary store. Every search reads the original logs, which one commenter timed at about twelve seconds, and that’s the trade-off for accuracy. Each quote comes with a byte offset and a hash, so you can check it against the original file. A quote you can re-verify is more reliable than one the model just says it found.
Q: Does finding an old message mean that decision still applies?
No. The tool shows what was said, not what still stands. A long working history will include decisions that were later reversed or dropped, and the search won’t flag them. Before you act on an old decision, read the conversation that came after it and look for a change of direction.
We Built a Local Search Tool for Codex Called “Oglyanutsya” (“Look Back”)
by u/Dream-SRA in PromptEngineering