Repository navigation
[Bug]: OmO creates huge log file due to EPIPE error #3772
Description
Prerequisites
- I will write this issue in English (see our Language Policy)
- I have searched existing issues to avoid duplicates
- I am using the latest version of oh-my-opencode
- I have read the documentation or asked an AI coding agent with this project's GitHub URL loaded and couldn't find the answer
Bug Description
oh-my-openagent writes session logs to disk (via session_output and transcript files) but imposes no size limit. On active projects or long sessions, logs grow unbounded — easily reaching multiple gigabytes on disk within days, clogging storage and making the .opencode/ directory painful to back up or clean.
There is no built-in log rotation, no truncation threshold, and no automatic cleanup of old session data.
Additionally, one specific error floods the logs unnecessarily during every shutdown:
[2026-05-03T08:39:19.874Z] [background-agent] uncaughtException received during shutdown cleanup: {"code":"EPIPE","fd":2,"syscall":"write","errno":-32}
This EPIPE error occurs because the background agent attempts to write to stderr after the parent process pipe has already closed. It is a harmless race condition — the process is shutting down anyway — but it logs this error on every session termination, compounding the log volume problem.
Steps to Reproduce
Open any oh-my-openagent session
Perform normal work (run tools, delegate tasks, etc.)
Check C:\Users\User\AppData\Local\Temp (or OS-based equivalent) — the error above appears in the log file
Repeat steps 1–4 across multiple sessions — log files accumulate with no rotation, with very fast population
Expected Behavior
Log files should respect a configurable maximum size (e.g. 100 MB per file)
A maximum number of retained log files should be configurable (e.g. 10 files)
Old files beyond the limit should be automatically deleted
The EPIPE race-condition error on shutdown should be caught and suppressed silently — it has no diagnostic value and only contributes noise and log volume
Actual Behavior
Every second, a log file is written to C:\Users\User\AppData\Local\Temp (on Windows)
The EPIPE error is written to logs every second
No maximum size or file count is enforced — logs grow indefinitely
Over time, multiple gigabytes of logs accumulate in %TEMP%
Doctor Output
oMoMoMoMo Doctor
✓ System OK (opencode unknown · oh-my-openagent unknown)Error Logs
A lot of:
[2026-05-03T08:39:19.874Z] [background-agent] uncaughtException received during shutdown cleanup: {"code":"EPIPE","fd":2,"syscall":"write","errno":-32}Configuration
Additional Context
Proposed Solution
Add a configurable log management in oh-my-openagent's config:
{
"logs": {
"max_size_mb": 100,
"max_files": 10,
"truncate_on_limit": true
}
}
max_size_mb: truncate or close session when log exceeds this sizemax_files: delete oldest logs when count exceeds this limittruncate_on_limit: if true, truncate the active log file rather than discarding it
Also, fix EPIPE error suppression during shutdown — it is a harmless race, not a meaningful error.
Alternatives Considered
- Manual cleanup only — document periodic cleaning of %TEMP%.opencode. Not acceptable; most users won't know and disk space issues are unexpected.
- OS-level cleanup — suggest Windows Task Scheduler or cron. Doesn't work reliably across platforms and places the burden on users.
- Compressed logs only — compress without size limits. Doesn't solve the growth problem.
Operating System
Windows
OpenCode Version
v1.14.33
Activity
vasilvestre commentedon May 4, 2026
It uses 100GB in some hours, terrible issue.
Mine write many times in the same milisecond.
umeraamir09 commentedon May 4, 2026
Can I work on this
PVLPM commentedon May 5, 2026
Yeah, behavior changes sometimes, I ended up creating a continuous task to delete the log file every second.
vasilvestre commentedon May 5, 2026
I've seen in htop that there's a background process that don't die with opencode. I don't know the reason but it seems to be my issue.
fix(shared): cap log file growth via size-based rotation
fix(shared): cap log file growth via size-based rotation
fix(shared): cap log file growth via size-based rotation
code-yeongyu commentedon May 16, 2026
[sisyphus-bot]
I checked the background-agent cleanup and logging paths.
The current code already contains a specific EPIPE recursion guard: it detaches the process-level error listener before logging during cleanup, which should address the old self-amplifying EPIPE log storm described here. However, the issue also mentions huge log growth and a background process that may not die with OpenCode. Those remaining symptoms could still come from another repeated shutdown error, missing log retention/rotation, or a shutdown path that is not actually reached.
Action taken: added
bugandtriage:needs-investigation. I am keeping this open until there is a current-HEAD repro showing whether the old EPIPE storm is gone and whether any lingering-process/log-growth path remains. No assignee for now because the blocker is fresh reproduction evidence.fix(shared): cap log file growth via size-based rotation
fix(background-agent): swallow EPIPE/ECONNRESET in shutdown error lis…
fix(background-agent): narrow EPIPE/ECONNRESET filter to stdio-or-shu…
Merge pull request #4355 from Yeachan-Heo/fix/issue-3772-epipe-log-bloat
code-yeongyu commentedon Jun 2, 2026
[sisyphus-dev] Follow-up from the bug sweep: #4355 is now merged and closes the remaining confirmed shutdown-stdio error storm path. Current
devalso already has shared logger rotation tests covering max-size rotation and backup retention. I treated configurable log-retention knobs as a separate product/policy request rather than part of this narrow bug fix; if fresh current-version evidence shows a different unbounded log path, please open a new issue with the current log path and process tree.