anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Failed to initialize OpenTUI render library: Failed to open library. #2493

New Issue
Closed
opened 2026-02-16 17:35:55 -05:00 by yindo · 27 comments
yindo commented 2026-02-16 17:35:55 -05:00
Owner
Copy Link
Copy Source

Originally created by @devahmedshendy on GitHub (Nov 2, 2025).

Originally assigned to: @kommander on GitHub.

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
> opencode

Screenshot and/or share link

No response

Operating System

macOS 15.7.1 (24G231)

Terminal

fishshell

Originally created by @devahmedshendy on GitHub (Nov 2, 2025). Originally assigned to: @kommander on GitHub. ### 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 ```bash > bun add -g opencode-ai > opencode ``` ### Screenshot and/or share link _No response_ ### Operating System macOS 15.7.1 (24G231) ### Terminal fishshell
yindo added the opentuibug labels 2026-02-16 17:35:55 -05:00
yindo closed this issue 2026-02-16 17:35:55 -05:00
yindo commented 2026-02-16 17:35:55 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 2, 2025):

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

  • #462: Add support for NixOS and/or Static linked binaries - This addresses the fundamental issue of missing system libraries that OpenTUI depends on
  • #3540: make opencode work w/ NixOS - Similar library initialization failures on NixOS systems
  • #649: running opencode fails in alpine / musl based distros - Same type of library linking issues on musl-based systems

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.

@github-actions[bot] commented on GitHub (Nov 2, 2025): This issue might be a duplicate of existing issues. Please check: - #462: Add support for NixOS and/or Static linked binaries - This addresses the fundamental issue of missing system libraries that OpenTUI depends on - #3540: make opencode work w/ NixOS - Similar library initialization failures on NixOS systems - #649: running opencode fails in alpine / musl based distros - Same type of library linking issues on musl-based systems 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.
yindo commented 2026-02-16 17:35:55 -05:00
Author
Owner
Copy Link
Copy Source

@guoqiao commented on GitHub (Nov 2, 2025):

+1, I also get this error after upgrade.

@guoqiao commented on GitHub (Nov 2, 2025): +1, I also get this error after upgrade.
yindo commented 2026-02-16 17:35:55 -05:00
Author
Owner
Copy Link
Copy Source

@thdxr commented on GitHub (Nov 2, 2025):

what cpu do you have

@thdxr commented on GitHub (Nov 2, 2025): what cpu do you have
yindo commented 2026-02-16 17:35:55 -05:00
Author
Owner
Copy Link
Copy Source

@guoqiao commented on GitHub (Nov 2, 2025):

what cpu do you have

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:

  • I tried all v1.0.0+ versions, with different ways to install (curl/zip/bun/brew), the same Failed to initialize OpenTUI render library error happened.
  • I also tried to install opentui with bun separately, still no help.
  • I have tried to remove old vesion completely and re-install, no help either.

I have downgraded to v0.15.31 (the last version before v1.0.0) and get it working for now.

@guoqiao commented on GitHub (Nov 2, 2025): > what cpu do you have 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: - I tried all v1.0.0+ versions, with different ways to install (curl/zip/bun/brew), the same `Failed to initialize OpenTUI render library` error happened. - I also tried to install opentui with bun separately, still no help. - I have tried to remove old vesion completely and re-install, no help either. I have downgraded to `v0.15.31` (the last version before v1.0.0) and get it working for now.
yindo commented 2026-02-16 17:35:55 -05:00
Author
Owner
Copy Link
Copy Source

@youngtai commented on GitHub (Nov 3, 2025):

Same error but thrown in a different place:

10033 | function resolveRenderLib() {
10034 |   if (!opentuiLib) {
10035 |     try {
10036 |       opentuiLib = new FFIRenderLib(opentuiLibPath);
10037 |     } catch (error) {
10038 |       throw new Error(`Failed to initialize OpenTUI render library: ${error instanceof Error ? error.message : "Unknown error"}`);
                    ^
error: Failed to initialize OpenTUI render library: Failed to open library "/$bunfs/root/libopentui-24nfw5wz.dylib": dlopen(/$bunfs/root/libopentui-24nfw5wz.dylib, 0x0001): tried: '/$bunfs/root/libopentui-24nfw5wz.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/$bunfs/root/libopentui-24nfw5wz.dylib' (no such file), '/$bunfs/root/libopentui-24nfw5wz.dylib' (no such file)
      at resolveRenderLib (../../node_modules/.bun/@opentui+core@0.1.33+81ecd8642a1892ca/node_modules/@opentui/core/index-xqg0a6ka.js:10038:13)
      at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.33+81ecd8642a1892ca/node_modules/@opentui/core/index-xqg0a6ka.js:12508:18)
      at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.33+81ecd8642a1892ca/node_modules/@opentui/core/index-xqg0a6ka.js:12499:34)
      at <anonymous> (../../node_modules/.bun/@opentui+solid@0.1.33+1753ef9b65046169/node_modules/@opentui/solid/index.js:904:26)
      at render (../../node_modules/.bun/@opentui+solid@0.1.33+1753ef9b65046169/node_modules/@opentui/solid/index.js:903:21)
      at <anonymous> (src/cli/cmd/tui/app.tsx:101:5)

Tried installing with the install script and npm - both same results.

Device: M4 Pro MBP
Opencode version: 1.0.18

@youngtai commented on GitHub (Nov 3, 2025): Same error but thrown in a different place: ``` 10033 | function resolveRenderLib() { 10034 | if (!opentuiLib) { 10035 | try { 10036 | opentuiLib = new FFIRenderLib(opentuiLibPath); 10037 | } catch (error) { 10038 | throw new Error(`Failed to initialize OpenTUI render library: ${error instanceof Error ? error.message : "Unknown error"}`); ^ error: Failed to initialize OpenTUI render library: Failed to open library "/$bunfs/root/libopentui-24nfw5wz.dylib": dlopen(/$bunfs/root/libopentui-24nfw5wz.dylib, 0x0001): tried: '/$bunfs/root/libopentui-24nfw5wz.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/$bunfs/root/libopentui-24nfw5wz.dylib' (no such file), '/$bunfs/root/libopentui-24nfw5wz.dylib' (no such file) at resolveRenderLib (../../node_modules/.bun/@opentui+core@0.1.33+81ecd8642a1892ca/node_modules/@opentui/core/index-xqg0a6ka.js:10038:13) at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.33+81ecd8642a1892ca/node_modules/@opentui/core/index-xqg0a6ka.js:12508:18) at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.33+81ecd8642a1892ca/node_modules/@opentui/core/index-xqg0a6ka.js:12499:34) at <anonymous> (../../node_modules/.bun/@opentui+solid@0.1.33+1753ef9b65046169/node_modules/@opentui/solid/index.js:904:26) at render (../../node_modules/.bun/@opentui+solid@0.1.33+1753ef9b65046169/node_modules/@opentui/solid/index.js:903:21) at <anonymous> (src/cli/cmd/tui/app.tsx:101:5) ``` Tried installing with the install script and `npm` - both same results. Device: M4 Pro MBP Opencode version: `1.0.18`
yindo commented 2026-02-16 17:35:55 -05:00
Author
Owner
Copy Link
Copy Source

@thdxr commented on GitHub (Nov 3, 2025):

if you have this error on mac does this work touch $TMPDIR/test.dylib

@thdxr commented on GitHub (Nov 3, 2025): if you have this error on mac does this work `touch $TMPDIR/test.dylib`
yindo commented 2026-02-16 17:35:55 -05:00
Author
Owner
Copy Link
Copy Source

@ErSoul commented on GitHub (Nov 3, 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.

Image
@ErSoul commented on GitHub (Nov 3, 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. <img width="1342" height="631" alt="Image" src="https://github.com/user-attachments/assets/515e717d-0c41-4751-94f5-0fb67bc5831d" />
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@devahmedshendy commented on GitHub (Nov 3, 2025):

@thdxr it is not allowed:

❯ touch $TMPDIR/test.dylib
touch: /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T//test.dylib: Permission denied
@devahmedshendy commented on GitHub (Nov 3, 2025): @thdxr it is not allowed: ``` ❯ touch $TMPDIR/test.dylib touch: /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T//test.dylib: Permission denied ```
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@thdxr commented on GitHub (Nov 4, 2025):

hm wonder why this is the case

CleanShot 2025-11-04 at 00.10.09@2x.png
@thdxr commented on GitHub (Nov 4, 2025): hm wonder why this is the case <img src="https://uploads.linear.app/a959060b-9262-4398-9650-16bf10f1450e/149d04ff-afd6-4bfd-84ea-37b8252c3a4a/7c3cf33b-b4cf-4755-8f46-510089737408?signature=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXRoIjoiL2E5NTkwNjBiLTkyNjItNDM5OC05NjUwLTE2YmYxMGYxNDUwZS8xNDlkMDRmZi1hZmQ2LTRiZmQtODRlYS0zN2I4MjUyYzNhNGEvN2MzY2YzM2ItYjRjZi00NzU1LThmNDYtNTEwMDg5NzM3NDA4IiwiaWF0IjoxNzYyMjMzMDQzLCJleHAiOjMzMzMyNzkzMDQzfQ.nW8BTL2LwEdY5RwhAwfQd7rix847jUbAaiFLCYwvxp0 " alt="CleanShot 2025-11-04 at 00.10.09@2x.png" width="2264" data-linear-height="2116" />
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@thdxr commented on GitHub (Nov 4, 2025):

TMPDIR=/tmp opencode

this doesn't work either right?

@thdxr commented on GitHub (Nov 4, 2025): `TMPDIR=/tmp opencode` this doesn't work either right?
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@devahmedshendy commented on GitHub (Nov 4, 2025):

@thdxr no no it works when running TMPDIR=/tmp opencode, that's it, can it work without issues after that?

Image 
❯ echo $TMPDIR
/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/

❯ ls -ld $TMPDIR
drwx------  64 root  wheel  2048 Nov  4 06:53 /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T//

❯ whoami
**** my username
@devahmedshendy commented on GitHub (Nov 4, 2025): @thdxr no no it works when running `TMPDIR=/tmp opencode`, that's it, can it work without issues after that? <img width="829" height="527" alt="Image" src="https://github.com/user-attachments/assets/7c279ec4-b61a-4218-a052-07384c594e00" /> ``` ❯ echo $TMPDIR /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/ ❯ ls -ld $TMPDIR drwx------ 64 root wheel 2048 Nov 4 06:53 /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T// ❯ whoami **** my username ```
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@devahmedshendy commented on GitHub (Nov 4, 2025):

btw, I didn't run any command in any restricted context, just open normal terminal and use it.

@devahmedshendy commented on GitHub (Nov 4, 2025): btw, I didn't run any command in any restricted context, just open normal terminal and use it.
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@marcomonsanto commented on GitHub (Nov 4, 2025):

Having the same issue on one of my macs.

My personal one worked as expected(M3 Pro) but in the company one(M2 Max) I get the same error.

I think the issue might be because the company one is a managed macbook where I have restricted access. The touch shows Permissions Denied, but the TMPDIR=/tmp opencode works as expected.

@marcomonsanto commented on GitHub (Nov 4, 2025): Having the same issue on one of my macs. My personal one worked as expected(M3 Pro) but in the company one(M2 Max) I get the same error. I think the issue might be because the company one is a managed macbook where I have restricted access. The `touch` shows Permissions Denied, but the `TMPDIR=/tmp opencode` works as expected.
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@shahidshabbir-se commented on GitHub (Nov 4, 2025):

Image

By setting TMPDIR to /tmp, I can successfully run opencode

@shahidshabbir-se commented on GitHub (Nov 4, 2025): <img width="1581" height="395" alt="Image" src="https://github.com/user-attachments/assets/4f430a9d-9f51-4a24-8a72-ecc73f27e4e2" /> By setting TMPDIR to /tmp, I can successfully run opencode
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@Universal-Invariant commented on GitHub (Nov 7, 2025):

Same issue on windows. Was just running with much older version and decided to update and getting that error.

@Universal-Invariant commented on GitHub (Nov 7, 2025): Same issue on windows. Was just running with much older version and decided to update and getting that error.
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@VDT-91 commented on GitHub (Nov 13, 2025):

I just got the same error on Windows 11, but for me its the Windows security that is flagging malware.

Image
@VDT-91 commented on GitHub (Nov 13, 2025): I just got the same error on Windows 11, but for me its the Windows security that is flagging malware. <img width="613" height="436" alt="Image" src="https://github.com/user-attachments/assets/204dac20-0b0d-4b3d-b63a-c571d8015b7d" />
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@zygou-31 commented on GitHub (Nov 18, 2025):

I don't now if this is related, but since version 1.0.56 I'm getting :

Image

This is expected since in my environment /tmp is mounted with noexec rights, so the .so lib is never going to work in there
I've tried setting TMPDIR or BUN_TEMP_DIR but whatever i try it always writes the .so lib in /tmp ...
Version 1.0.56 shipped the version 1.0.39 of opentui. Do you think this an issue with opentui or with opencode ?

@zygou-31 commented on GitHub (Nov 18, 2025): I don't now if this is related, but since version 1.0.56 I'm getting : ![Image](https://github.com/user-attachments/assets/58358665-895e-4a09-9181-e383787546bd) This is expected since in my environment /tmp is mounted with noexec rights, so the .so lib is never going to work in there I've tried setting TMPDIR or BUN_TEMP_DIR but whatever i try it always writes the .so lib in /tmp ... Version 1.0.56 shipped the version 1.0.39 of opentui. Do you think this an issue with opentui or with opencode ?
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@devahmedshendy commented on GitHub (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.

@devahmedshendy commented on GitHub (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.
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@apdt commented on GitHub (Nov 19, 2025):

I'm seeing this issue on 1.0.78:

$ opencode 
^[\10486 | function resolveRenderLib() {
10487 |   if (!opentuiLib) {
10488 |     try {
10489 |       opentuiLib = new FFIRenderLib(opentuiLibPath);
10490 |     } catch (error) {
10491 |       throw new Error(`Failed to initialize OpenTUI render library: ${error instanceof Error ? error.message : "Unknown error"}`);
                    ^
error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.fa797eeecf37f6f5-00000001.so": /tmp/.fa797eeecf37f6f5-00000001.so: failed to map segment from shared object
      at resolveRenderLib (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:10491:13)
      at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12993:18)
      at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12984:34)
      at <anonymous> (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:904:26)
      at render (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:903:21)
      at <anonymous> (src/cli/cmd/tui/app.tsx:102:5)

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) :

$ TMPDIR=~/tmp2 opencode --print-logs --log-level DEBUG
INFO  2025-11-19T15:49:09 +222ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode
^[\ERROR 2025-11-19T15:49:10 +375ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object Unhandled rejection
ERROR 2025-11-19T15:49:10 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object rejection
ERROR 2025-11-19T15:49:10 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object
@apdt commented on GitHub (Nov 19, 2025): I'm seeing this issue on 1.0.78: ``` $ opencode ^[\10486 | function resolveRenderLib() { 10487 | if (!opentuiLib) { 10488 | try { 10489 | opentuiLib = new FFIRenderLib(opentuiLibPath); 10490 | } catch (error) { 10491 | throw new Error(`Failed to initialize OpenTUI render library: ${error instanceof Error ? error.message : "Unknown error"}`); ^ error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.fa797eeecf37f6f5-00000001.so": /tmp/.fa797eeecf37f6f5-00000001.so: failed to map segment from shared object at resolveRenderLib (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:10491:13) at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12993:18) at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12984:34) at <anonymous> (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:904:26) at render (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:903:21) at <anonymous> (src/cli/cmd/tui/app.tsx:102:5) ``` 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)` : ``` $ TMPDIR=~/tmp2 opencode --print-logs --log-level DEBUG INFO 2025-11-19T15:49:09 +222ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode ^[\ERROR 2025-11-19T15:49:10 +375ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object Unhandled rejection ERROR 2025-11-19T15:49:10 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object rejection ERROR 2025-11-19T15:49:10 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object ```
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@Universal-Invariant commented on GitHub (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.

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:

10033 | function resolveRenderLib() {
10034 |   if (!opentuiLib) {
10035 |     try {
10036 |       opentuiLib = new FFIRenderLib(opentuiLibPath);
10037 |     } catch (error) {
10038 |       throw new Error(`Failed to initialize OpenTUI render library: ${error instanceof Error ? error.message : "Unknown error"}`);
                    ^
error: Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-8b8p1y9r.dll": error code 126
      at resolveRenderLib (../../node_modules/.bun/@opentui+core@0.1.33+81ecd8642a1892ca/node_modules/@opentui/core/index-xqg0a6ka.js:10038:13)
      at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.33+81ecd8642a1892ca/node_modules/@opentui/core/index-xqg0a6ka.js:12508:18)
      at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.33+81ecd8642a1892ca/node_modules/@opentui/core/index-xqg0a6ka.js:12499:34)
      at <anonymous> (../../node_modules/.bun/@opentui+solid@0.1.33+1753ef9b65046169/node_modules/@opentui/solid/index.js:904:26)
      at render (../../node_modules/.bun/@opentui+solid@0.1.33+1753ef9b65046169/node_modules/@opentui/solid/index.js:903:21)
      at <anonymous> (src/cli/cmd/tui/app.tsx:103:5)
@Universal-Invariant commented on GitHub (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. 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: ``` 10033 | function resolveRenderLib() { 10034 | if (!opentuiLib) { 10035 | try { 10036 | opentuiLib = new FFIRenderLib(opentuiLibPath); 10037 | } catch (error) { 10038 | throw new Error(`Failed to initialize OpenTUI render library: ${error instanceof Error ? error.message : "Unknown error"}`); ^ error: Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-8b8p1y9r.dll": error code 126 at resolveRenderLib (../../node_modules/.bun/@opentui+core@0.1.33+81ecd8642a1892ca/node_modules/@opentui/core/index-xqg0a6ka.js:10038:13) at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.33+81ecd8642a1892ca/node_modules/@opentui/core/index-xqg0a6ka.js:12508:18) at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.33+81ecd8642a1892ca/node_modules/@opentui/core/index-xqg0a6ka.js:12499:34) at <anonymous> (../../node_modules/.bun/@opentui+solid@0.1.33+1753ef9b65046169/node_modules/@opentui/solid/index.js:904:26) at render (../../node_modules/.bun/@opentui+solid@0.1.33+1753ef9b65046169/node_modules/@opentui/solid/index.js:903:21) at <anonymous> (src/cli/cmd/tui/app.tsx:103:5) ```
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@Universal-Invariant commented on GitHub (Nov 19, 2025):

I'm seeing this issue on 1.0.78:

$ opencode 
^[\10486 | function resolveRenderLib() {
10487 |   if (!opentuiLib) {
10488 |     try {
10489 |       opentuiLib = new FFIRenderLib(opentuiLibPath);
10490 |     } catch (error) {
10491 |       throw new Error(`Failed to initialize OpenTUI render library: ${error instanceof Error ? error.message : "Unknown error"}`);
                    ^
error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.fa797eeecf37f6f5-00000001.so": /tmp/.fa797eeecf37f6f5-00000001.so: failed to map segment from shared object
      at resolveRenderLib (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:10491:13)
      at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12993:18)
      at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12984:34)
      at <anonymous> (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:904:26)
      at render (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:903:21)
      at <anonymous> (src/cli/cmd/tui/app.tsx:102:5)

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) :

$ TMPDIR=~/tmp2 opencode --print-logs --log-level DEBUG
INFO  2025-11-19T15:49:09 +222ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode
^[\ERROR 2025-11-19T15:49:10 +375ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object Unhandled rejection
ERROR 2025-11-19T15:49:10 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object rejection
ERROR 2025-11-19T15:49:10 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object

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

 opencode --print-logs --log-level DEBUG
INFO  2025-11-19T16:08:20 +104ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode
ERROR 2025-11-19T16:08:20 +147ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 Unhandled rejection
ERROR 2025-11-19T16:08:20 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 rejection
ERROR 2025-11-19T16:08:20 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126

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.

@Universal-Invariant commented on GitHub (Nov 19, 2025): > I'm seeing this issue on 1.0.78: > > ``` > $ opencode > ^[\10486 | function resolveRenderLib() { > 10487 | if (!opentuiLib) { > 10488 | try { > 10489 | opentuiLib = new FFIRenderLib(opentuiLibPath); > 10490 | } catch (error) { > 10491 | throw new Error(`Failed to initialize OpenTUI render library: ${error instanceof Error ? error.message : "Unknown error"}`); > ^ > error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.fa797eeecf37f6f5-00000001.so": /tmp/.fa797eeecf37f6f5-00000001.so: failed to map segment from shared object > at resolveRenderLib (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:10491:13) > at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12993:18) > at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12984:34) > at <anonymous> (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:904:26) > at render (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:903:21) > at <anonymous> (src/cli/cmd/tui/app.tsx:102:5) > ``` > > 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)` : > > ``` > $ TMPDIR=~/tmp2 opencode --print-logs --log-level DEBUG > INFO 2025-11-19T15:49:09 +222ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode > ^[\ERROR 2025-11-19T15:49:10 +375ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object Unhandled rejection > ERROR 2025-11-19T15:49:10 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object rejection > ERROR 2025-11-19T15:49:10 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object > ``` 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 ``` opencode --print-logs --log-level DEBUG INFO 2025-11-19T16:08:20 +104ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode ERROR 2025-11-19T16:08:20 +147ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 Unhandled rejection ERROR 2025-11-19T16:08:20 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 rejection ERROR 2025-11-19T16:08:20 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 ``` 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.
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@apdt commented on GitHub (Nov 19, 2025):

I'm seeing this issue on 1.0.78:

$ opencode 
^[\10486 | function resolveRenderLib() {
10487 |   if (!opentuiLib) {
10488 |     try {
10489 |       opentuiLib = new FFIRenderLib(opentuiLibPath);
10490 |     } catch (error) {
10491 |       throw new Error(`Failed to initialize OpenTUI render library: ${error instanceof Error ? error.message : "Unknown error"}`);
                    ^
error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.fa797eeecf37f6f5-00000001.so": /tmp/.fa797eeecf37f6f5-00000001.so: failed to map segment from shared object
      at resolveRenderLib (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:10491:13)
      at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12993:18)
      at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12984:34)
      at <anonymous> (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:904:26)
      at render (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:903:21)
      at <anonymous> (src/cli/cmd/tui/app.tsx:102:5)

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) :

$ TMPDIR=~/tmp2 opencode --print-logs --log-level DEBUG
INFO  2025-11-19T15:49:09 +222ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode
^[\ERROR 2025-11-19T15:49:10 +375ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object Unhandled rejection
ERROR 2025-11-19T15:49:10 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object rejection
ERROR 2025-11-19T15:49:10 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object

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

 opencode --print-logs --log-level DEBUG
INFO  2025-11-19T16:08:20 +104ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode
ERROR 2025-11-19T16:08:20 +147ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 Unhandled rejection
ERROR 2025-11-19T16:08:20 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 rejection
ERROR 2025-11-19T16:08:20 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126

I don't know why anyone is hard coding paths, even if it is just in the output in this day and age. In the since v1.0.77 it seems someone just removed displaying the error on windows since it just hangs without any error.

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?

@apdt commented on GitHub (Nov 19, 2025): > > I'm seeing this issue on 1.0.78: > > ``` > > $ opencode > > ^[\10486 | function resolveRenderLib() { > > 10487 | if (!opentuiLib) { > > 10488 | try { > > 10489 | opentuiLib = new FFIRenderLib(opentuiLibPath); > > 10490 | } catch (error) { > > 10491 | throw new Error(`Failed to initialize OpenTUI render library: ${error instanceof Error ? error.message : "Unknown error"}`); > > ^ > > error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.fa797eeecf37f6f5-00000001.so": /tmp/.fa797eeecf37f6f5-00000001.so: failed to map segment from shared object > > at resolveRenderLib (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:10491:13) > > at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12993:18) > > at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12984:34) > > at <anonymous> (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:904:26) > > at render (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:903:21) > > at <anonymous> (src/cli/cmd/tui/app.tsx:102:5) > > ``` > > > > > > > > > > > > > > > > > > > > > > > > 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)` : > > ``` > > $ TMPDIR=~/tmp2 opencode --print-logs --log-level DEBUG > > INFO 2025-11-19T15:49:09 +222ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode > > ^[\ERROR 2025-11-19T15:49:10 +375ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object Unhandled rejection > > ERROR 2025-11-19T15:49:10 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object rejection > > ERROR 2025-11-19T15:49:10 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object > > ``` > > 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 > > ``` > opencode --print-logs --log-level DEBUG > INFO 2025-11-19T16:08:20 +104ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode > ERROR 2025-11-19T16:08:20 +147ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 Unhandled rejection > ERROR 2025-11-19T16:08:20 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 rejection > ERROR 2025-11-19T16:08:20 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 > ``` > > I don't know why anyone is hard coding paths, even if it is just in the output in this day and age. In the since v1.0.77 it seems someone just removed displaying the error on windows since it just hangs without any error. 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?
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@Universal-Invariant commented on GitHub (Nov 19, 2025):

I'm seeing this issue on 1.0.78:

$ opencode 
^[\10486 | function resolveRenderLib() {
10487 |   if (!opentuiLib) {
10488 |     try {
10489 |       opentuiLib = new FFIRenderLib(opentuiLibPath);
10490 |     } catch (error) {
10491 |       throw new Error(`Failed to initialize OpenTUI render library: ${error instanceof Error ? error.message : "Unknown error"}`);
                    ^
error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.fa797eeecf37f6f5-00000001.so": /tmp/.fa797eeecf37f6f5-00000001.so: failed to map segment from shared object
      at resolveRenderLib (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:10491:13)
      at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12993:18)
      at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12984:34)
      at <anonymous> (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:904:26)
      at render (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:903:21)
      at <anonymous> (src/cli/cmd/tui/app.tsx:102:5)

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) :

$ TMPDIR=~/tmp2 opencode --print-logs --log-level DEBUG
INFO  2025-11-19T15:49:09 +222ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode
^[\ERROR 2025-11-19T15:49:10 +375ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object Unhandled rejection
ERROR 2025-11-19T15:49:10 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object rejection
ERROR 2025-11-19T15:49:10 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object

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

 opencode --print-logs --log-level DEBUG
INFO  2025-11-19T16:08:20 +104ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode
ERROR 2025-11-19T16:08:20 +147ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 Unhandled rejection
ERROR 2025-11-19T16:08:20 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 rejection
ERROR 2025-11-19T16:08:20 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126

I don't know why anyone is hard coding paths, even if it is just in the output in this day and age. In the since v1.0.77 it seems someone just removed displaying the error on windows since it just hangs without any error.

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?

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.

@Universal-Invariant commented on GitHub (Nov 19, 2025): > > > I'm seeing this issue on 1.0.78: > > > ``` > > > $ opencode > > > ^[\10486 | function resolveRenderLib() { > > > 10487 | if (!opentuiLib) { > > > 10488 | try { > > > 10489 | opentuiLib = new FFIRenderLib(opentuiLibPath); > > > 10490 | } catch (error) { > > > 10491 | throw new Error(`Failed to initialize OpenTUI render library: ${error instanceof Error ? error.message : "Unknown error"}`); > > > ^ > > > error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.fa797eeecf37f6f5-00000001.so": /tmp/.fa797eeecf37f6f5-00000001.so: failed to map segment from shared object > > > at resolveRenderLib (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:10491:13) > > > at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12993:18) > > > at createCliRenderer (../../node_modules/.bun/@opentui+core@0.1.41+81ecd8642a1892ca/node_modules/@opentui/core/index-kj9k00yt.js:12984:34) > > > at <anonymous> (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:904:26) > > > at render (../../node_modules/.bun/@opentui+solid@0.1.41+1753ef9b65046169/node_modules/@opentui/solid/index.js:903:21) > > > at <anonymous> (src/cli/cmd/tui/app.tsx:102:5) > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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)` : > > > ``` > > > $ TMPDIR=~/tmp2 opencode --print-logs --log-level DEBUG > > > INFO 2025-11-19T15:49:09 +222ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode > > > ^[\ERROR 2025-11-19T15:49:10 +375ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object Unhandled rejection > > > ERROR 2025-11-19T15:49:10 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object rejection > > > ERROR 2025-11-19T15:49:10 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "/tmp/.d97d732dff7fbff3-00000001.so": /tmp/.d97d732dff7fbff3-00000001.so: failed to map segment from shared object > > > ``` > > > > > > 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 > > ``` > > opencode --print-logs --log-level DEBUG > > INFO 2025-11-19T16:08:20 +104ms service=default version=1.0.78 args=["--print-logs","--log-level","DEBUG"] opencode > > ERROR 2025-11-19T16:08:20 +147ms service=acp-command promise={} reason=Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 Unhandled rejection > > ERROR 2025-11-19T16:08:20 +0ms service=default e=Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 rejection > > ERROR 2025-11-19T16:08:20 +0ms service=default Error: Failed to initialize OpenTUI render library: Failed to open library "B:/~BUN/root/opentui-t13tdp88.dll": error code 126 > > ``` > > > > > > > > > > > > > > > > > > > > > > > > I don't know why anyone is hard coding paths, even if it is just in the output in this day and age. In the since v1.0.77 it seems someone just removed displaying the error on windows since it just hangs without any error. > > 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](https://github.com/Universal-Invariant) is seeing though might point to something? 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.
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@pmarreck commented on GitHub (Nov 22, 2025):

A few cross-platform notes about TMPDIR and mktemp that may be relevant, which I encountered:

  1. Linux /tmp is almost always an ephemeral RAMdisk via being formatted as tmpfs.

  2. Mac mktemp by 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 what TMPDIR is set to, unless you specify $TMPDIR as part of the template argument to mktemp, or pass --tmpdir to it (see below).

  3. On my Mac, I added a setup that puts /tmp on a RAMdisk when I log in, so I can enjoy the advantages of not wearing down my SSD, but there's a catch: /tmp is 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:

export TMPDIR="/tmp/$$" # a canonical process-ID-specific temp directory
mkdir -p "$TMPDIR" # because mktemp won't work unless it already exists
export TMPDIR=$(realpath "$TMPDIR") # to resolve to the physical path

To convince mktemp, gmktemp (the GNU version, if you're on Mac and it's installed) to actually USE TMPDIR, you can pass --tmpdir to it when you call it.

@pmarreck commented on GitHub (Nov 22, 2025): A few cross-platform notes about `TMPDIR` and `mktemp` that may be relevant, which I encountered: 1) Linux /tmp is almost always an ephemeral RAMdisk via being formatted as `tmpfs`. 2) Mac `mktemp` by 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 what `TMPDIR` is set to_, unless you specify `$TMPDIR` as part of the template argument to `mktemp`, or pass `--tmpdir` to it (see below). 3) On my Mac, I added a setup that puts `/tmp` on a RAMdisk when I log in, so I can enjoy the advantages of not wearing down my SSD, but there's a catch: `/tmp` is 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: ``` export TMPDIR="/tmp/$$" # a canonical process-ID-specific temp directory mkdir -p "$TMPDIR" # because mktemp won't work unless it already exists export TMPDIR=$(realpath "$TMPDIR") # to resolve to the physical path ``` To convince `mktemp`, `gmktemp` (the GNU version, if you're on Mac and it's installed) to actually USE `TMPDIR`, you can pass `--tmpdir` to it when you call it.
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@Universal-Invariant commented on GitHub (Nov 22, 2025):

A few cross-platform notes about TMPDIR and mktemp that may be relevant, which I encountered:

  1. Linux /tmp is almost always an ephemeral RAMdisk via being formatted as tmpfs.
  2. Mac mktemp by 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 what TMPDIR is set to, unless you specify $TMPDIR as part of the template argument to mktemp, or pass --tmpdir to it (see below).
  3. On my Mac, I added a setup that puts /tmp on a RAMdisk when I log in, so I can enjoy the advantages of not wearing down my SSD, but there's a catch: /tmp is 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:

export TMPDIR="/tmp/$$" # a canonical process-ID-specific temp directory
mkdir -p "$TMPDIR" # because mktemp won't work unless it already exists
export TMPDIR=$(realpath "$TMPDIR") # to resolve to the physical path

To convince mktemp, gmktemp (the GNU version, if you're on Mac and it's installed) to actually USE TMPDIR, you can pass --tmpdir to it when you call it.

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.

@Universal-Invariant commented on GitHub (Nov 22, 2025): > A few cross-platform notes about `TMPDIR` and `mktemp` that may be relevant, which I encountered: > > 1. Linux /tmp is almost always an ephemeral RAMdisk via being formatted as `tmpfs`. > 2. Mac `mktemp` by 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 what `TMPDIR` is set to_, unless you specify `$TMPDIR` as part of the template argument to `mktemp`, or pass `--tmpdir` to it (see below). > 3. On my Mac, I added a setup that puts `/tmp` on a RAMdisk when I log in, so I can enjoy the advantages of not wearing down my SSD, but there's a catch: `/tmp` is 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: > > ``` > export TMPDIR="/tmp/$$" # a canonical process-ID-specific temp directory > mkdir -p "$TMPDIR" # because mktemp won't work unless it already exists > export TMPDIR=$(realpath "$TMPDIR") # to resolve to the physical path > ``` > > To convince `mktemp`, `gmktemp` (the GNU version, if you're on Mac and it's installed) to actually USE `TMPDIR`, you can pass `--tmpdir` to it when you call it. 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.
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@kommander commented on GitHub (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.

@kommander commented on GitHub (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.
yindo commented 2026-02-16 17:35:56 -05:00
Author
Owner
Copy Link
Copy Source

@Universal-Invariant commented on GitHub (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.

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.

@Universal-Invariant commented on GitHub (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. 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug opentui
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2493
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?