PRO-LONG: an append-only session log plus a search skill for coding agents

The failure PRO-LONG is aimed at: compaction erases decisions, not just text

The README states the problem directly: long tasks outlive context windows, and after compaction or a fresh session a coding agent can lose earlier decisions, repeat failed work, and miss tool results it already paid for. That is a narrower complaint than general context loss. The expensive failures are the repeated ones. An agent that re-runs a failing migration command, re-reads a file it already understood, or re-proposes an approach the user rejected two sessions ago burns tokens and time on work that was already resolved. PRO-LONG targets that specific loop. It is for people who drive a coding CLI through multi-session work on a single repository and want the prior history to be queryable rather than replayed. It is not a general agent framework, and the README does not present it as one.

One append-only log, and retrieval by ordinary shell tools

The mechanism is deliberately thin. A project-local adapter appends prompts, tool activity, assistant handoffs and session boundaries to .prolong/log.jsonl. Nothing is summarised, embedded or indexed. When prior work matters, a skill file tells the agent how to search that log using rg, jq or Python, and to read only the matching entries. The README's flow diagram shows three nodes: coding agent, log file, relevant prior context, with the log feeding context back only on demand. Two design choices stand out. First, the log is never injected wholesale into the prompt, so the cost of memory stays proportional to what the agent actually retrieves. Second, reads of the log are excluded from recording, which prevents retrieval from copying memory back into itself and growing the file on every lookup. That recursion guard is the detail that makes an append-only file viable over a long project. The trade-off is that retrieval quality now depends on the agent writing a good rg or jq query. There is no ranking, no relevance scoring and no embedding search. If the agent searches for the wrong string, it finds nothing, and nothing in the design catches that.

Install path: clone, build, link, then prolong init inside your project

The quick start is a Node toolchain even though the repository is listed as Python. The README gives these commands: git clone https://github.com/alexisfox7/PRO-LONG.git && cd PRO-LONG, then npm install && npm run build && npm link, then cd into your own project and run prolong init. The CLI has exactly three commands. prolong init detects supported clients on PATH; prolong status checks the skill, runtime and client integrations, and accepts --json for automation; prolong uninstall removes the integration while preserving the log, with --purge to delete the recorded history. To pick clients explicitly, prolong init --client codex,claude-code,opencode,pi. The integration surface differs per client: .codex/hooks.json lifecycle hooks for Codex, .claude/settings.json for Claude Code, .opencode/plugins/prolong.ts for OpenCode, and .pi/extensions/prolong.ts for pi. init also writes .prolong/runtime.mjs, .prolong/install.json, .agents/skills/prolong/SKILL.md, a managed pointer in AGENTS.md, a managed .prolong/ entry in .gitignore, and for Claude Code a pointer in CLAUDE.md. The README warns that hooks and extensions run with your user permissions and that you should review the generated integration and accept the client's trust prompt. That warning is worth taking literally: a hook that runs on every lifecycle event is code execution inside your project.

The research numbers are not a benchmark of the shipped tool

The headline figure, 97.4% best@2 on the full ARC-AGI-3 public game set, comes from the research harness described in arXiv:2607.20064, which the README says improved over matched coding-agent baselines by 18 percentage points on average. The README then states plainly that these results motivate the product design and are not yet a direct benchmark of the coding-tool MVP. That sentence is the most useful one in the document. It means there is no published measurement here of whether the log-and-skill approach reduces repeated work in a real repository, and no comparison against a coding agent running without PRO-LONG on the same task. The reproduction code and logs live under research/arc-agi-3/ for anyone who wants to check the original setup. Until someone runs that comparison, the case for installing PRO-LONG rests on the mechanism being plausible, not on a number.

Privacy is a hard constraint, not a configuration detail

The log stays inside the project and is gitignored by default, but the README is blunt about what it can contain: prompts, assistant messages, tool inputs, tool results, and any secrets that appeared in them. That is a real constraint on where this tool is appropriate. A repository that handles credentials, customer data or regulated material will accumulate all of it in a plain JSONL file that any process running as your user can read. The README's guidance is to avoid enabling transcript retention where local policy forbids it, and to run prolong uninstall --purge when the history should be removed. Note that uninstall without --purge leaves the log in place by design, so removing the integration is not the same as removing the data. There is also no described redaction step, no field allowlist and no size cap on the log. On a long project the file grows monotonically, and every retrieval is a scan over it.

What it is not: no server, no database, no cross-project memory

The README contrasts PRO-LONG with approaches that dump a transcript into the prompt or stand up a wrapper, server or database. The alternative it implicitly rejects is the retrieval-service pattern, where an external process embeds and indexes session history and answers similarity queries. That pattern buys ranking and relevance, and it pays for them with a running service, a vector store and an indexing pipeline to keep in sync. PRO-LONG's difference is that the retrieval step is the agent's own shell access to a file. You get transparency, since the log is readable JSONL and the query is visible, and you get zero infrastructure. What you give up is recall when the agent does not know the right search term, and any memory that survives outside the project directory. Two projects running PRO-LONG have two unrelated logs. For a single long-running repository that is fine. For someone who wants an agent to remember a preference across every repository they work in, this design does not attempt it.

Upgrade cost and licence terms

There are no retrieved releases, so there is no changelog to diff against and no version pinning documented in the README. The only dated entry is August 19, 2026, when coding-CLI memory was added. That matters for upgrades because init writes files into your project: hooks, a plugin or extension, a skill, AGENTS.md, a .gitignore entry, and for Claude Code a CLAUDE.md pointer. The README describes the pointers as managed and .prolong/install.json as the manifest used by status and uninstall, which suggests re-running init is the intended update path, but the document does not spell out what happens to a modified hook file on re-init. Treat the generated integration as project configuration you own and review after any upgrade. The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice; if your organisation has rules about hook execution or transcript retention, those rules govern regardless of what MIT allows.

Editorial conclusion

Adopt PRO-LONG if you already run Codex, Claude Code, OpenCode or pi on a project whose tasks routinely outlive one context window, and you are willing to read the generated hook or plugin before trusting it. Do not adopt it if your repository cannot hold prompts, tool inputs and tool results on disk, or if you need a retrieval layer that works across projects. Before relying on it, run prolong status --json after init and confirm the client integration, the skill and the runtime all report as present, then check that .prolong/log.jsonl is actually receiving entries during a real session.

Official sources

1. alexisfox7/PRO-LONG on GitHub
2. Issues
3. License: MIT
4. README