Repository navigation
Bug Report: Rollout Log Size Explosion from Unbounded Base64 Image Data #32128
Copy link
Copy link
Open
Labels
CLIIssues related to the Codex CLIIssues related to the Codex CLIbugSomething isn't workingSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving
Description
Bug Report: Rollout Log Size Explosion from Unbounded Base64 Image Data
Environment
- Codex CLI Version: 0.142.5 (desktop build 26.707.3748.0)
- Platform: Windows 11
- Storage:
~/.codex/sessions/and~/.codex/logs_2.sqlite
Problem
Codex's rollout JSONL logging system stores full base64-encoded image data directly in function_call_output and message payload fields. This causes exponential log growth:
- A single session with image operations can grow to 15-16 MB (normally a session should be < 1 MB)
- 94.6% of the inflated session size is base64 image data embedded in
data:image/png;base64,...strings - The largest single JSON line observed: 4.8 MB (one base64 image)
- Cumulative base64 across all sessions: 11.3 MB in image data alone
Root Cause Analysis
function_call_outputpayloads store complete base64 image strings fromimage_url.urlfields (format:data:image/png;base64,iVBORw0...)- These are written verbatim to JSONL files without any size limit or truncation
session_metaduplicatesbase_instructionstext (~20 KB) in every session file- SQLite WAL files are not periodically checkpointed, causing
logs_2.sqlite-walandstate_5.sqlite-walto grow
Impact
| Metric | Before Fix | After Fix (estimated) |
|---|---|---|
| Single session (with images) | 15.6 MB | < 1 MB |
| Total session rollouts | 110 MB | ~35 MB |
| WAL files (uncheckpointed) | 8 MB | < 1 MB with auto-checkpoint |
| Total disk savings | ~75 MB (60%+) |
Evidence
- Largest session: 2118 lines, 515 function_call_output entries, 2 base64 occurrences totaling 4.67 MB
- All sessions combined: 31,770 response_items, 12,947 function_call_outputs, 11.3 MB total base64
- Base64 accounts for 94.6% of function output size in affected sessions
Proposed Solutions
P0: Filter/Truncate base64 in function_call_output
Detect data:image/*;base64,<string> patterns and replace with [BASE64_IMAGE_DATA_REMOVED]
P1: Add configurable log size limits
[logging]
max_response_item_size = 10000
max_base64_per_output = 1024P2: Auto-checkpoint SQLite WAL on idle/close
Execute PRAGMA wal_checkpoint(PASSIVE) when a session ends or app goes idle
P3: Deduplicate base_instructions in session_meta
Store in a shared file, reference by hash/path instead of duplicating ~20 KB per session
Severity
High - Rapid disk consumption (hundreds of MB in days of normal use), can fill SSDs on limited-storage devices.
Reported by: user diagnosing their own Codex installation
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
CLIIssues related to the Codex CLIIssues related to the Codex CLIbugSomething isn't workingSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving
Activity
github-actions commentedon Jul 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action