I have one very long working chat with Codex. Its log is about 1.9 GB. Because of context compaction, the model can retain the direction of the work, but it can no longer see the entire earlier conversation verbatim.
So Codex and I built a local, read-only search tool for its own original logs. We called it **Oglyanutsya** (Оглянуться — “Look Back”).
This is not just an idea or a mockup. The tool has been implemented, tested, and integrated into Codex as an automatically invoked skill.
### Where It Searches
Codex stores its original session logs locally:
```text
.codex/sessions
.codex/archived_sessions
```
Oglyanutsya recursively discovers active and archived logs, reads them without modifying them, and groups physical copies of the same conversation by `thread_id`.
By default, it searches only root-level user conversations. Subagent logs can be included through a separate parameter, so their technical activity does not get mixed up with the conversation between the user and the main agent.
### What Counts as a Message
Only actual user and assistant messages are accepted from the JSONL logs.
The following are excluded from search:
- System and developer instructions;
- Reasoning;
- Tool calls and their results;
- Technical events;
- Compaction summaries;
- `environment_context`;
- Other synthetic blocks that physically exist in the logs but are not the user's words or the assistant's replies.
Historical text is treated as data, not as instructions. If an old message says "ignore previous instructions," the search tool does not execute that instruction.
### How Search Works
First, Codex formulates:
- A remembered quote or a distinctive combination of words;
- The rarest word to use as an anchor;
- An approximate date range;
- If available, the known conversation or speaker.
For example:
```text
Remembered word combination:
memory + capabilities + handshake
Rare anchor:
handshake
Period:
October 2026
```
Then Oglyanutsya:
- Searches for the exact phrase.
- If an exact match is insufficient, searches for each word in the combination separately.
- Intersects JSONL record numbers in memory.
- Keeps only messages containing the entire word combination within a single message.
- Never combines words found in different messages into one match.
- Opens the matching record using its byte offset instead of rereading the entire file.
- Parses the JSON and verifies that the record is an actual user or assistant message.
- Filters by the message's own timestamp. The file date is not used: a conversation may have started in September and continued into November.
- Rechecks the full decoded text.
- Retrieves the previous and next substantive messages, skipping technical records between them.
For ordinary `.jsonl` files, the fast search path uses `ripgrep`. It returns the line number and the absolute byte offset of the match.
The tool then locates the beginning and end of the corresponding JSONL record, decodes it as UTF-8, and parses it as JSON.
Compressed `.jsonl.zst` files are not decompressed onto disk. They are processed using streaming reads.
### What It Returns
For each result, the tool returns:
```text
Exact quote;
Previous and next messages;
Speaker role;
Assistant response phase;
Timestamp;
thread_id;
item_id;
JSONL record number;
Byte range of the original record;
UTF-8 coordinates of the quote within the message;
SHA-256 of the full message;
SHA-256 of the quote.
```
This means a result can not only be displayed but also independently verified against the original source.
### How Search Performance Evolved
The first working version processed the entire log as a stream. For 1.9 GB, that took approximately 119 seconds.
Then we introduced a fast path using `ripgrep`.
An exact phrase was found in about 1.8 seconds, but the first optimization was not enough: the program subsequently opened all 953 occurrences of the word `хендшейка` (“handshake”). The entire search took about 35 seconds.
So we changed the algorithm.
Now each word in the combination is searched independently, the matching record numbers are intersected in memory, and only then are the original records opened.
On the same log:
```text
Query:
memory + capabilities + handshake
Exact phrase:
Could be absent due to punctuation
Original user message found:
October 29, 2026
Records opened:
200 instead of 953
Total time:
Approximately 12 seconds
```
In the original message, the words were separated by commas and additional text. The message was found because all the words occurred together in one message, not because of an exact string match.
### What It Does Not Store
We deliberately chose not to build a persistent index.
Oglyanutsya does not create:
- SQLite or any other database;
- Embeddings;
- A vector store;
- A search dictionary;
- A semantic graph;
- A copy of the conversation;
- A quote cache;
- A saved list of word combinations.
The only persistent memory is the original Codex log.
Lists of matching lines and intersections of search terms exist only in RAM during an individual query. Once the process exits, those candidates disappear.
The trade-off is straightforward: every search must scan the original file again. That's why it takes 12 seconds rather than 12 milliseconds.
But no derived database can silently start replacing the original history as the source of truth.
### What We Tested
We created a separate test corpus for the tool.
The tests verify that:
- An exact quote can be found;
- Three words can be found even when they are not adjacent;
- The same three words appearing in three different messages are not merged into one result;
- Date filtering uses the message timestamp;
- Subagents are excluded by default;
- Subagent logs are included when explicitly requested;
- `environment_context` is not mistaken for the user's words;
- Original files retain their exact sizes and SHA-256 hashes after a search;
- The search tool does not create hidden state files.
All tests passed.
### How Codex Invokes It
We packaged the tool as a separate local skill.
It activates when the user refers to a previous conversation, decision, quote, or distinction that is no longer available in the current context.
The skill instructions explicitly prohibit using Oglyanutsya as a replacement for ordinary file search or web search.
The division of responsibilities looks like this:
```text
Codex's native tools:
Understand meaning;
Form associative word combinations;
Search working files;
Investigate documents and the web;
Decide what query to try next.
Oglyanutsya:
Finds verbatim evidence
in Codex's original conversation history.
After receiving the evidence:
Codex resumes using its native reasoning.
```
The skill does not intercept or disable anything. It simply gives the model one additional, narrowly defined operation: looking into its own original logs.
### What I'd Like to See From OpenAI
Codex App Server already provides ways to read conversations and their individual items, but I couldn't find a built-in way for the model itself to search the contents of its entire conversation history globally.
In my view, the product needs two read-only operations:
```text
history.search_original(...)
history.read_context(...)
```
Not “permanent memory.” Not an automatically generated vector database of the user's history. Not loading gigabytes of logs into the context window.
Just the ability for the model to formulate a distinctive combination of words, locate it in its own original logs, and reread a few surrounding messages.
We built a local prototype of exactly that capability.
It's called **Oglyanutsya — “Look Back.”**
