If You Disable Codex’s SQLite Logs, What Keeps Your Project Memory Alive?

Developers have recently been discussing Codex continuously writing large amounts of diagnostic data into:

~/.codex/logs_2.sqlite

The visible database may remain relatively small while its SQLite WAL file keeps receiving frequent writes in the background.

Some users have reported:

• excessive SSD writes;
• rapidly growing WAL files;
• slower responses;
• lock contention;
• startup or session reliability problems.

One unofficial workaround is to add a SQLite trigger that ignores new inserts into the logging table.

That may reduce the disk-writing problem.

But it also exposes a deeper architectural question:

If you disable an agent’s internal logs, what preserves the memory required to continue the project?

Diagnostic logs and project memory are not the same thing

An agent’s internal logs are primarily designed for the agent application itself.

They may contain:

• network events;
• trace output;
• runtime state transitions;
• low-level debugging information;
• internal operational details.

Those logs can be useful for diagnosing Codex.

But they are not necessarily what the next coding agent needs when it resumes your project tomorrow.

The next agent usually needs something much smaller and more meaningful:

• Which file is the current ground truth?
• What decision was made?
• Why was that decision made?
• Which approaches have already failed?
• What evidence has been verified?
• What remains unfinished?
• What should happen next?

That is project continuity.

It is not diagnostic telemetry.

What happens when you block the logs?

The trigger workaround attempts to stop new rows from being inserted into Codex’s local logging database.

The intended operational effect is straightforward:

• reduce repeated SQLite writes;
• slow or stop WAL growth;
• reduce SSD pressure;
• potentially improve responsiveness.

But it is still an unofficial workaround that modifies Codex’s internal database behavior.

It may reduce diagnostic visibility.

It may behave differently after a future Codex schema migration.

It may interfere with debugging.

It should not be presented as a guaranteed or permanent fix.

More importantly, it should not be treated as a project-memory strategy.

Even if Codex logging worked perfectly, an internal diagnostic database would still be the wrong place to depend on for durable project continuity.

Its schema belongs to Codex.

Its retention policy belongs to Codex.

Its format can change with Codex.

Its purpose is to help Codex operate and diagnose itself—not to preserve the smallest verified context required by the next agent.

The real performance gap is continuity performance

When developers hear “agent performance,” they usually think about:

• model quality;
• response speed;
• token usage;
• tool execution;
• latency.

There is another kind of performance that matters just as much:

How quickly can a new session recover the correct context and continue working?

I call this continuity performance.

A fast model that spends twenty minutes rediscovering decisions, reopening the wrong files, repeating failed experiments, or misunderstanding the project’s current state is not performing well at the project level.

This becomes especially visible when:

• the original session is gone;
• context has been compacted;
• the transcript is too large;
• the agent changes;
• local logs are cleared;
• an internal database is disabled;
• a tool changes its storage format.

The problem is not that every trace event disappeared.

The problem is that the next agent no longer knows what matters.

Where QiJu fits

QiJu is now publicly available on PyPI:

uv tool install qiju

It is a local-first, lossless record layer for AI coding agents.

It works with:

• Claude Code;
• Codex;
• Kiro;
• Cursor.

QiJu does not try to preserve every conversation line or every tool event.

It intentionally records the smaller set of facts that allow work to continue:

• the ground-truth file or artifact;
• the decision that was made;
• the evidence supporting it;
• the result that was verified;
• the unresolved risk;
• the next action.

A later Codex session—or Claude Code, Kiro, or Cursor—can search those records and continue from the correct state.

The goal is not to reconstruct the entire old session.

The goal is to help the next agent continue correctly.

QiJu is not “memory”

This distinction is important.

QiJu does not make a model remember more.

It creates an explicit record layer.

Ordinary agent memory tries to answer:

What does the model remember?

QiJu tries to answer:

• Why do we know this?
• Where is the proof?
• Who produced the result?
• Was it verified?
• What should happen next?
• Which agent should continue?

That makes the work auditable and handoffable instead of trapped inside one tool’s internal recall.

A useful way to think about it is:

Codex logs tell Codex what happened internally.
QiJu tells the next agent what matters for continuing the work.

A practical example

Imagine a Codex session has just completed a packaging migration.

During the work, the agent discovered that:

• the public package must move to src/qiju/;
• pyproject.toml must remain the version authority;
• runtime JSON must be loaded through package resources;
• uninstalling the CLI must preserve user records;
• all supported coding-agent hosts must pass installed-wheel testing.

A complete transcript may contain tens of thousands of words around those conclusions.

The durable project record can be much smaller:

Ground truth:
design/pypi-packaging-execution-plan.md
Decision:
Use one canonical src/qiju package for source and PyPI installs.
Verified:
Wheel and sdist passed artifact inspection and installed-wheel smoke tests.
Rejected:
Renaming scripts to qiju only during the staging build.
Next:
Publish to TestPyPI and repeat the clean-install lifecycle test.

That is enough for the next agent to find the right file, understand the decision, and continue from the correct point.

It does not need every trace message.

It needs the right record.

The new update problem

Once QiJu is installed through PyPI, users can upgrade the CLI with:

uv tool upgrade qiju

But that creates another subtle problem.

The CLI may be updated while the copied SKILL.md files inside existing projects remain stale.

Those skills tell Claude Code, Codex, Kiro, and Cursor how to call QiJu.

So upgrading only the executable is not enough.

QiJu 0.5.3 adds:

qiju update

This refreshes the installed QiJu skills across registered projects.

Typical usage:

uv tool upgrade qiju
qiju update

You can also preview changes:

qiju update --dry-run

Refresh only one host:

qiju update --host codex

Or scan and backfill older projects that were created before the registry existed:

qiju update --scan-projects

This matters because continuity depends not only on preserving records, but also on keeping the agent integration itself current.

How project registration works

When you initialize QiJu in a project:

cd /path/to/project
qiju init --host codex

QiJu registers the project location.

Each project’s own:

.qiju/config.json

remains the source of truth for which hosts are enabled.

The registry tells QiJu where projects are.

The project config tells QiJu how each project is wired.

That separation allows qiju update to refresh projects without relying only on heuristic filesystem scans.

It also means projects outside standard search roots can still be updated, as long as they were registered during initialization.

For older installs, one migration command is enough:

qiju update --scan-projects

After that, ordinary updates can remain fast and deterministic.

What QiJu does not do

QiJu does not:

• fix Codex’s SQLite logging behavior;
• stop SSD writes by itself;
• replace Codex diagnostics;
• guarantee that the unofficial database trigger is safe;
• preserve the Codex conversation interface;
• reproduce every internal event from the previous session;
• silently ingest all transcripts or prompts;
• use embeddings or vector memory.

Capture is intentional.

You—or the agent under your instruction—decide what is worth recording.

That boundary is important.

QiJu is not another background logger.

It is the opposite: a deliberate, inspectable record of what matters.

A real workflow

Install QiJu:

uv tool install qiju

Connect it to a project:

cd /path/to/project
qiju init --host codex

During the session, ask the agent to record what matters:

$qiju-log

Later, in another session or another agent:

$qiju-search the last packaging decision

After upgrading QiJu:

uv tool upgrade qiju
qiju update

That keeps both the CLI and the installed agent skills current.

Why this matters after disabling logs

Suppose you apply the SQLite trigger workaround and Codex stops writing most of its local diagnostic events.

Operationally, that may reduce disk pressure.

But now the separation becomes clear:

Codex diagnostics
→ reduced or unavailable
QiJu project records
→ still available
Ground-truth files
→ still referenced
Decisions
→ still searchable
Next steps
→ still recoverable

The next agent may not know every internal event from the previous Codex run.

It does not need to.

It needs to know:

• what was decided;
• why;
• where the evidence is;
• what was verified;
• what to do next.

That is how QiJu helps maintain continuity performance even when Codex’s internal logging is limited or cleared.

The broader design lesson

The Codex logging issue is a reminder that developers often mix several different kinds of memory:

1. Diagnostics — what happened inside the application.
2. Conversation history — what the user and agent said.
3. Repository state — what currently exists in the codebase.
4. Decision history — why the project reached its current state.
5. Continuation context — what the next agent needs to do next.

No single SQLite log, transcript, or Git repository fully represents all five.

Git can show what changed, but not always why.

A transcript may show why, but it can be too large and tied to one tool.

Diagnostic logs show runtime behavior, but mostly contain noise from the project’s perspective.

A durable agent workflow needs an explicit project record layer.

Current limits

QiJu is still in developer preview.

At the time of writing:

• it supports macOS and Linux;
• Windows is not yet supported or tested;
• capture is intentional rather than automatic;
• retrieval is deterministic keyword, tag, and regex search;
• there are no embeddings or semantic ranking;
• the CLI and host wiring may still evolve.

Those limits are deliberate.

The current priority is reliability, inspectability, and ownership.

My conclusion

Blocking noisy Codex logs may be a reasonable temporary response to excessive disk writes, provided users understand that it is unofficial and may affect diagnostics.

But the deeper conclusion is more important:

Your project memory should not disappear when an agent’s internal logs are disabled, cleared, corrupted, or redesigned.

Codex logs tell Codex what happened internally.

QiJu records the ground truth, decisions, evidence, and next steps that another agent needs to continue.

That separation lets you reduce dependence on internal diagnostic logs without sacrificing project continuity.

QiJu is available now:

uv tool install qiju

Project page:

https://pypi.org/project/qiju/

Source:

https://github.com/jasonshrepo/qiju

Star if you like QiJu(起居).

The question I am most interested in is:

If you stopped trusting your coding agent’s internal history tomorrow, what would you preserve so another agent could continue correctly?