opencode creates identical temp files everytime it runs

Description

I run opencode stats periodically to monitor my token and tool usage.

However, I found a new Library file .*-00000000.so is created under /tmp directory whenever I run opencode. The file is not removed after opencode is terminated.

Each file is sized ~4.1MB. These behaviours consumed 60+ GB just over a night.

OpenCode version

1.0.218

Steps to reproduce

Run watch opencode stats
Wait for a while
run ls -lah /tmp

Screenshot and/or share link

Operating System

Ubuntu 24.04

Terminal

Bash

This issue might be a duplicate of existing issues. Please check:

[BUG] Ubuntu 22.04 Temp_Pack Files Using All of the Storage #5617: [BUG] Ubuntu 22.04 Temp_Pack Files Using All of the Storage - Similar issue with temporary files consuming excessive disk space
Security Issue: Suspicious Temporary Libraries Loaded by OpenCode Process #5792: Security Issue: Suspicious Temporary Libraries Loaded by OpenCode Process - Related issue about suspicious temporary files (.dylib/.node) being created in temp directories

Feel free to ignore if none of these address your specific case.

The situation is closer to what has been mentioned in #5792 . I don't consider this as a security issue at the moment.

However, not cleaning up files after exit and consumes more than 60+ GB is the issue here.

To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.

The issue still persists in 1.3.2.

Steps to reproduce:

ls -l /tmp/.*.so -> if there are these files, delete them to start test from scratch
Start opencode
Invoke /exit
ls -l /tmp/.*.so
witness there are new matching files in /tmp

This test doesn't produce .*.hm files, though, maybe those are created when the model is actually used. I do believe they are also relevant, because they otherwise follow the same naming pattern, e.g. /tmp/.7cfffffbb7f1ed57-00000000.hm.

@eras

@eras Thanks for confirming. I have stopped using Open Code because of this issue.
TBH, I would like this issue to be addressed by a human, sincerely.

Using opencode serve on a remote VPS, this issue was eating up drive space and breaking orchestration. As a workaround I did the following (possibly not safe - but hasn't broken me yet):

file: /etc/systemd/system/opencode-tmp-clean.service

[Unit]
Description=Clean stale OpenCode temporary shared libraries
Documentation=https://github.com/anomalyco/opencode/issues/16996

[Service]
Type=oneshot
ExecStart=/usr/local/bin/opencode-tmp-cleanup
User=root

file: /etc/systemd/system/opencode-tmp-clean.timer

[Unit]
Description=Periodic cleanup of stale OpenCode temporary shared libraries

[Timer]
OnBootSec=10m
OnUnitActiveSec=30m
AccuracySec=5m
Persistent=true
Unit=opencode-tmp-clean.service

[Install]
WantedBy=timers.target

file: /usr/local/bin/opencode-tmp-cleanup

#!/usr/bin/env python3

import os
import sys
import time
import re
from pathlib import Path


TMP_DIR = Path("/tmp")
# Matches exactly: .<16 hex chars>-00000000.so
SO_PATTERN = re.compile(r'^\.[0-9a-fA-F]{16}-00000000\.so$')

MAX_AGE_SECONDS = 60 * 60   # 1 hour

def main() -> int:
    now = time.time()
    deleted = 0
    freed = 0

    try:
        entries = list(TMP_DIR.iterdir())
    except OSError as exc:
        print(f"opencode-tmp-cleanup: failed to read {TMP_DIR}: {exc}", file=sys.stderr)
        return 1

    for path in entries:
        if not path.is_file():
            continue

        name = path.name
        if not SO_PATTERN.match(name): 
            continue

        try:
            stat = path.stat()
        except OSError:
            continue

        if now - stat.st_mtime < MAX_AGE_SECONDS:
            continue

        try:
            path.unlink()
        except FileNotFoundError:
            continue
        except OSError as exc:
            print(f"opencode-tmp-cleanup: failed to delete {path}: {exc}", file=sys.stderr)
            continue

        deleted += 1
        freed += stat.st_size

    print(f"opencode-tmp-cleanup: deleted={deleted} freed_bytes={freed}")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

fix(session): read opencode session list from SQLite, not subprocess (#…

@khwong-c

6 months later, still very much an issue. Really feeling what @khwong-c said:

TBH, I would like this issue to be addressed by a human, sincerely.

Have we seriously turned software development into talking to automated voice messaging systems? Because people seemed to love those and they worked so well?

@mikew

@mikew I tried to add a tear emoji in your reply but couldn't find one 😂

So here you go: 🥲

This issue can be serious vulnerability.

I thought that running opencode stats is a very harmless thing and did it in loop in my terminal: watch -n 2 "opencode stats" to monitor some metrics while working.

After a few hours my /tmp folder was full of .9dfdcffffcfabcbd-00000000.so-like files. My system start jitterring, I begin to investigate. The first query in google give me possible rootkit activity and the evening starts heating up. I was near to reinstalling my system, at least, thinking where to backup my data urgently. Finally after 2 hours of investigation with virustotal and lsof for files, I ended up with this issue and this comment.

Guys please escalate priority for that issue, it is definitely not minor.

The subsequent run should not create new similar .so file, at least opencode should clean up it after exit.

Thinking of fixing it, but I am not very familiar with typescript, I am a Python developer. If someone going to do it urgently feel free to do so.

For the reference, my investigation flow:

I restarted Firefox/Pycharm, thinking one of them is the issue
in an end of day, I did sudo apt update as my regular routine
the apt says 'no free space on device' or smth
I did df -hT to clear the things up
and see tmpfs /tmp has 0 bytes of free space
then ls -lha /tmp gives me approximately 7000 results
then google said possible rootkit activity
~2 hours of working with lsof, virustotal, etc
and now I am here

I think this can happen to everyone so I writing things up in details.

Update: the unbounded native-library temp-file growth described here is fixed in OpenCode V2.

As of V2 build 0.0.0-dev-17643, the compiled CLI uses Bun 1.4.0-canary.1 (681a49bee). That runtime includes oven-sh/bun#29587, which replaces the unique temporary .so/.dylib/.node extraction on every load with a deterministic, content-hashed path reused across calls, Workers, processes, and restarts. The V2 build provenance is workflow run 32216069554.

This bounds extraction to one reusable file per embedded native module and user instead of allowing unbounded disk growth. It does not mean the temp directory will contain zero native files, and upgrading does not remove files leaked by older builds; those stale randomly named files can be cleaned up after all older OpenCode processes have stopped.

Navigation Menu

Repository navigation

opencode creates identical temp files everytime it runs #6523

Description

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

opencode creates identical temp files everytime it runs #6523

Description

Description

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

github-actions commented on Dec 31, 2025

khwong-c commented on Dec 31, 2025

github-actions commented on Mar 25, 2026

eras commented on Mar 25, 2026

khwong-c commented on Mar 25, 2026

snarkipus commented on Apr 3, 2026

mikew commented on May 15, 2026

khwong-c commented on May 15, 2026

andyceo commented on May 18, 2026

thdxr commented on Aug 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions