Repository navigation
Failed to initialize OpenTUI render library: Failed to open library. #3765
Description
Description
I just installed opencode and failed to start it for first time
❯ opencode
9971 | onAnyNativeEvent(handler) {
9972 | this._anyEventHandlers.push(handler);
9973 | }
9974 | }
9975 | var opentuiLibPath;
9976 | var opentuiLib;
^
error: Failed to initialize OpenTUI render library: Failed to open library. This is usually caused by a missing library or an invalid library path.
at resolveRenderLib (../../node_modules/.bun/@opentui+core@0.1.32+81ecd8642a1892ca/node_modules/@opentui/core/index-3f9h747j.js:9976:5)
at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.32+81ecd8642a1892ca/node_modules/@opentui/core/index-3f9h747j.js:12441:3)
at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.32+81ecd8642a1892ca/node_modules/@opentui/core/index-3f9h747j.js:12432:28)
at <anonymous> (../../node_modules/.bun/@opentui+solid@0.1.32+1753ef9b65046169/node_modules/@opentui/solid/index.js:893:1)
at render (../../node_modules/.bun/@opentui+solid@0.1.32+1753ef9b65046169/node_modules/@opentui/solid/index.js:892:7)
at <anonymous> (src/cli/cmd/tui/app.tsx:95:7)
Whether I install is using brew, bun, npm .. I get same result.
OpenCode version
1.0.11
Steps to reproduce
> bun add -g opencode-ai
> opencodeScreenshot and/or share link
No response
Operating System
macOS 15.7.1 (24G231)
Terminal
fishshell
Activity
github-actions commentedon Nov 2, 2025
This issue might be a duplicate of existing issues. Please check:
The "Failed to initialize OpenTUI render library" error suggests missing system-level dependencies, which is exactly what these issues track. Your specific platform details (OS, distribution, installation method) would help determine if this is the same underlying problem.
Feel free to ignore if none of these address your specific case.
guoqiao commentedon Nov 2, 2025
+1, I also get this error after upgrade.
thdxr commentedon Nov 3, 2025
what cpu do you have
guoqiao commentedon Nov 3, 2025
I am using opencode on a home server with old i5 cpu:
CPU: Intel i5-9400F (6) @ 4.100GHz
OS: Ubuntu 24.04.3 LTS x86_64
PS:
Failed to initialize OpenTUI render libraryerror happened.I have downgraded to
v0.15.31(the last version before v1.0.0) and get it working for now.youngtai commentedon Nov 3, 2025
Same error but thrown in a different place:
Tried installing with the install script and
npm- both same results.Device: M4 Pro MBP
Opencode version:
1.0.18thdxr commentedon Nov 4, 2025
if you have this error on mac does this work
touch $TMPDIR/test.dylibErSoul commentedon Nov 4, 2025
I'm having this same error for windows. Same result from NPM & the bash script with curl; and for git-bash, cmd, and powershell.
devahmedshendy commentedon Nov 4, 2025
@thdxr it is not allowed:
thdxr commentedon Nov 4, 2025
hm wonder why this is the case
thdxr commentedon Nov 4, 2025
TMPDIR=/tmp opencodethis doesn't work either right?
devahmedshendy commentedon Nov 4, 2025
@thdxr no no it works when running
TMPDIR=/tmp opencode, that's it, can it work without issues after that?devahmedshendy commentedon Nov 4, 2025
btw, I didn't run any command in any restricted context, just open normal terminal and use it.
5 remaining items
devahmedshendy commentedon Nov 19, 2025
I noticed the issue is no more happening in version
1.0.68. I can open opencode safely without the error reported in this issue.I will close the issue, and me or anyone can reopen it once I issue arise again.
apdt commentedon Nov 19, 2025
I'm seeing this issue on 1.0.78:
After a little testing, I tried forcing TMPDIR, with debug logging and it doesn't appear to be respecting the TMPDIR value and seems hardwired to use /tmp which in our org is mounted
(rw,nosuid,nodev,noexec,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota):Universal-Invariant commentedon Nov 19, 2025
It should then be easy to track down to figure out what it could have been? Better if someone could figure out what the likely cause was for the future since it might return.
I just updated to v1.0.49 -> v1.0.78 and I get no TUI or warning now or anything. Just sits there in the terminal without returning to it unless I ctrl-z. This is on windows 24H2.
For me, the issue starts with the v1.0.0 TUI rewrite. v0.15.31 works fine. v1.0.0 TUI rewrite gives:
Universal-Invariant commentedon Nov 19, 2025
and hasn't worked since v1.0.0 for me on windows. It's very likely there are some hard coded paths or assumptions made which is causing the same error on windows. E.g., there is no /tmp on windows and if yours is blocked and it's assuming /tmp then that could explain the problem. But this goes back to v1.0.0 for me so
I don't know why anyone is hard coding paths, even if it is just in the output, in this day and age. v1.0.77 looks like someone just removed displaying the error on windows since it just hangs without any error but with print-logs it shows that it has the same problem.
apdt commentedon Nov 19, 2025
So after some searching, for me, 1.0.56 does not work and 1.0.55 does work. This should help identify the cause for my issue, but probably doesn't help what @Universal-Invariant is seeing though might point to something?
Universal-Invariant commentedon Nov 19, 2025
https://github.com/sst/opentui/blob/8e307896a463321df881b7f68348954eca9014dc/packages/core/src/zig.ts#L2910
This is the code that is outputting the error. What could solve this very quickly is some way to set the opentui path to use from the command line. Then we can at least force it. I downloaded the opentui.dll for windows. I thought about creating that path putting it in there and it might work if there are not version issues but it wouldn't really solve the problem. I could also use procmon to determine if it is actually looking for the file there but I think someone who can easily patch this needs to look at it. Again, the easiest way would be to somehow allow us to configure the openTUI path. I have no B drive so where it is getting B from is ridiculous. Someone said it was just something hard coded and irrelevant but looking at the code suggests otherwise.
pmarreck commentedon Nov 22, 2025
A few cross-platform notes about
TMPDIRandmktempthat may be relevant, which I encountered:Linux /tmp is almost always an ephemeral RAMdisk via being formatted as
tmpfs.Mac
mktempby default returns a file or directory of the form/var/folders/xx/yyyyyyyy/...which is a user-specific directory that cannot be accessed by other users; this design was for security reasons; to my knowledge, it is stored on your SSD (and thus wears it down over time) and not in RAM. It will do this regardless of whatTMPDIRis set to, unless you specify$TMPDIRas part of the template argument tomktemp, or pass--tmpdirto it (see below).On my Mac, I added a setup that puts
/tmpon a RAMdisk when I log in, so I can enjoy the advantages of not wearing down my SSD, but there's a catch:/tmpis symlinked to/private/tmp.As a result of all of the above, and because I'm more concerned about SSD wear than other users (of which there are none set up on my laptops besides me) having access to my tmpfiles, here is my cross-platform dotfile setup for TMPDIR:
To convince
mktemp,gmktemp(the GNU version, if you're on Mac and it's installed) to actually USETMPDIR, you can pass--tmpdirto it when you call it.Universal-Invariant commentedon Nov 22, 2025
On windows I essentially do the same where I have a ramdisk using AIM toolkit. I recently switched over from ImDisk because ImDisk has a bug in it which causes some programs to error out when accessing Temp. The error is rare enough that I don't know if it solves it or not I saw someone mention that it did.
In any case, this doesn't seem to be the problem with opencode AFAICT. At least on windows it seems it cannot find the opentui library as it is looking at it in a hardcoded or ill configured path. It may be different issues for different architectures but given how they all center around the exact same error msg suggests it's a bug with configuring paths. Why using TmpDir works for some and not others is strange. Possibly it resolves the path somewhere in the code so that the dlls can be found.
kommander commentedon Dec 20, 2025
Improvements for windows have been made in the latest versions, did that get better? The tmpdir access issue is a bun issue. You can use BUN_TMPDIR as a workaround.
Universal-Invariant commentedon Dec 20, 2025
Its seems very different. This time I get a windows installer for opencode and when I installed it I then get a gui window for it rather than it being in the console. I guess that means it is working? I guess that was the TUI change? If so then it seems to be working as expected now. I didn't do anything with the BUN_TMPDIR.
ChazenLi commentedon Mar 6, 2026
I know this issue was originally reported on macOS, but I wanted to add a Windows-specific diagnostic and fix for the same symptom family:
In my case, the visible symptom looked very similar to this issue, but the actual root cause was more specific:
opencode serve --port <port> --hostname 127.0.0.1worked normally.opencodedid not enter the TUI.（Error code 225 indicates Windows Defender rejection）So for my machine, this was not:
It was specifically a Windows security / Defender rejection of the temporary DLL extracted for the TUI renderer.
How I Isolated It
The key step was separating backend health from TUI startup.
I first ran:
That started successfully and listened on the expected address, which told me the backend was healthy.
Then I ran plain
opencodewith debug logs:This consistently failed during OpenTUI initialization, not during backend startup.
That distinction mattered a lot: if
serveworks butopencodefails during renderer init, the problem is likely in the TUI render library loading path, not in the server/runtime as a whole.What did NOT fix it
These actions did not solve the problem for me:
opencodeTEMP/TMPdirectoryChanging
TEMP/TMPby itself did move the extracted DLL to another drive, but Windows still rejected loading it.What DID fix it
The complete fix required creating a dedicated temp directory, pointing the environment variables there, and adding a Windows Defender exclusion. Here are the exact steps:
Step 1: Create a dedicated temp directory
Step 2: Set TEMP and TMP for the current session (Test First)
Then test:
Note: In my case, the error still happened here, but the log now pointed to a DLL under
F:\OpenCodeTemp\...dll, which confirmed that the issue was not the original%LOCALAPPDATA%\Temppath itself.Step 3: Make TEMP / TMP permanent for the user
After opening a new PowerShell session, I verified:
(On my machine this later displayed the Windows short path form, e.g.,
F:\OPENCO~1, which is completely normal).Step 4: Add a Defender exclusion for that directory
This was the step that actually fixed it. In an elevated (Administrator) PowerShell:
You can verify it with:
Step 5: Restart terminal and launch again
After reopening PowerShell:
At that point, the TUI started normally.
Practical Conclusion
If someone hits this issue on Windows and sees the generic OpenTUI failure message, I would strongly recommend checking whether it is actually this more specific variant:
opencode serve ...works.opencodefails.If that pattern matches, the problem is likely Windows Defender blocking the extracted OpenTUI render DLL, and the workaround above should help.
snajjar commentedon Mar 12, 2026
Same issue here on linux. It worked before, didn't change anything, but now
opencode serveoropencode runworks.opencodedoesn't work anymore (endless start).Workaround:
Investigation shows that deleting
/tmp/*.soand thenLD_BIND_NOW=1 opencodefixes the issue, if it helps someone here 👍It seems that opencode extract opentui lib in tmpfs and never clean up. I didn't check yet, but seeing the number, it seems to be doing that for every subagent launched. At some point, tmpfs is full and opencode doesn't work anymore.
Forcing the linker to solve all references at starts seems to do the trick.
disarticulate commentedon Apr 27, 2026
I had to clear /tmp; it overfillth. Would be nice to have a sanity check.
FireCulex commentedon Jul 6, 2026
I was confused by this error myself