Codex CLI on Linux repeatedly creates hidden libopentui .so files in /tmp until tmpfs fills up

[davidj4tech]

What version of Codex CLI is running?

v0.121.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Linux sp4 6.15.3-arch1-2-surface x86_64

What terminal emulator and version are you using (if applicable)?

kitty

What issue are you seeing?

While Codex is running on Linux, it repeatedly creates hidden shared-library files in /tmp with names like:

/tmp/.5ff7a7ff9e7df777-00000000.so

These files are about 4.3 MiB each and accumulate over time until /tmp fills completely.

My /tmp is mounted as tmpfs with a 3.9 GiB limit, so this eventually reaches 100% usage and starts breaking unrelated programs that need temp space.

The files are easy to miss because they are hidden dotfiles.

I inspected one of the extracted .so files and it appears to be libopentui.so / terminal UI renderer code. Sample strings from one extracted file included:

libopentui.so
createRenderer
setupTerminal
render
setTerminalTitle
restoreTerminalModes

One sample file was identified as:

ELF 64-bit LSB shared object, x86-64, dynamically linked, with debug_info, not stripped

What steps can reproduce the bug?

1. Start Codex on Linux with /tmp mounted as tmpfs.
2. Use Codex normally for a while, or resume a session.
3. Watch /tmp with:

find /tmp -maxdepth 1 -type f -name '.*.so' -printf '%TY-%Tm-%Td %TH:%TM:%TS %s %p\n' | sort

4. Observe repeated creation of new hidden 4.3 MiB .so files.

I also tested deleting all hidden /.so and /.node files from /tmp and then watching for regrowth. New .so files reappeared immediately while Codex was still running.

What is the expected behavior?

Codex should not keep extracting duplicate shared libraries into /tmp.

If runtime extraction is required, it should reuse a stable path or clean up properly instead of creating unbounded hidden temp files.

Additional information

A 15 second watch window after cleanup showed immediate regrowth:

14:15:55 count=1 size=4.3 MiB
14:15:58 count=2 size=8.6 MiB
14:16:01 count=4 size=17.1 MiB
14:16:04 count=4 size=17.1 MiB
14:16:07 count=5 size=21.4 MiB

Sample recreated files:

2026-04-19 14:15:55 4484680 /tmp/.5ff7a7f65edd57f7-00000000.so
2026-04-19 14:15:57 4484680 /tmp/.5ff7a7f6dd5fd3af-00000000.so
2026-04-19 14:15:59 4484680 /tmp/.5ff7a7f7587d57bd-00000000.so
2026-04-19 14:16:01 4484680 /tmp/.5ff7a7f7d6fd93ff-00000000.so
2026-04-19 14:16:06 4484680 /tmp/.5ff7a7ff097d7f65-00000000.so

At one point before cleanup I had:

• 919 non-empty hidden .so files
• total size about 3929 MiB

Temporary workaround:

find /tmp -maxdepth 1 -type f -name '.*.so' -user "$USER" -delete

I can provide more details if needed, but the core symptom seems clear: the CLI is repeatedly materializing hidden libopentui shared objects into /tmp and never reusing or cleaning them up.

[etraut-openai]

I don't think Codex is doing this. To my knowledge (and also backed up by an analysis by codex), Codex doesn't use opentui. This must be something else running on your system.