Codex app repeatedly writes large SQLite etilqs temp files from internal Guardian thread metadata

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App 26.707.51957 (build 5175); bundled codex-cli 0.144.0-alpha.4

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

The native Codex process repeatedly creates and writes large SQLite temporary files named etilqs_* under the macOS temporary directory, even while the app is otherwise idle.

In a 314.6-second fs_usage trace:

• Total WrData: 510.6 MB (about 140.3 GB/day if sustained)
• Direct writes by codex: 304.6 MB (59.6% of all writes)
• Writes to etilqs_*: 285.0 MB (55.8% of all writes and 93.6% of direct Codex writes)
• 13 separate SQLite temp files were created
• The first was about 44.2 MB; subsequent files were usually about 21-22 MB
• The pattern repeated every 18-42 seconds

This is not the previously reported TRACE-log WAL insertion issue. During the same trace, writes to logs_2.sqlite-wal were only 20 KB, and the logs table was empty because inserts had already been disabled.

The behavior appears tied to oversized metadata for internal Guardian threads in state_5.sqlite. The database contained 1,338 thread rows. Across all rows, each of title, preview, and first_user_message totaled about 16.1 MB. In 1,193 rows, all three fields were exactly identical. There were 784 titles longer than 1,000 characters, with a maximum title length of 81,403 characters. Most of this data came from internal rows whose source was {"subagent":{"other":"guardian"}}.

These internal Guardian threads remained unarchived, were apparently included in thread-list/search work, and could not be archived through the supported thread API, which returned No Codex thread found for an internal Guardian thread ID.

What steps can reproduce the bug?

1. Use the Codex desktop app for many tasks that create internal auto-review/Guardian subagents.
2. Allow completed internal Guardian thread rows to accumulate in ~/.codex/state_5.sqlite.
3. Quit unrelated high-I/O applications where practical, then run:

sudo fs_usage -w -f diskio -t 300 Codex codex

1. Observe repeated writes by the native codex process to files named etilqs_* in the macOS temporary directory, typically every 18-42 seconds.
2. Inspect state_5.sqlite read-only and group active threads by source. Check the lengths and equality of title, preview, and first_user_message.
3. On an affected database, internal Guardian rows contain very long conversation-like text duplicated into all three fields and remain unarchived after the internal task has completed.

No single user session ID appears to be responsible; the issue accumulates across many internal Guardian threads.

What is the expected behavior?

Completed internal Guardian threads should not remain in the active user-visible thread index with full conversation text duplicated into title, preview, and first_user_message.

Thread titles and previews should have reasonable length limits. Internal threads should be automatically archived or excluded from normal thread-list/search queries. An idle Codex app should not repeatedly spill tens of megabytes into SQLite temporary files every 18-42 seconds.

Additional information

I backed up the databases before testing a mitigation. Archiving 512 completed Guardian rows older than one hour directly in state_5.sqlite reduced the active thread-list metadata payload from about 48.5 MB to 2.54 MB. No rollout JSONL files or conversation content were deleted.

A 45-second SMART sample after that change measured 23.55 MB written, or 0.523 MB/s. A prior 25-second sample during the affected behavior measured 21.48 MB/s. That is an approximately 97.6% reduction in the short-interval device write rate, strongly linking the excessive writes to the active Guardian-thread metadata/thread-list path.

The SSD itself reports healthy status, 2% percentage used, 100% available spare, and zero media/data-integrity errors. The concern is unnecessary write amplification and long-term SSD wear caused by repeated SQLite temp-file generation.

I have intentionally not attached the raw database or trace because they may contain private conversation data, but I can provide a redacted trace if needed.