Security Issue: Suspicious Temporary Libraries Loaded by OpenCode Process

[jishankai]

Description

I've discovered suspicious temporary libraries being loaded by the OpenCode process that appear to pose potential security risks. These files are being created and loaded from temporary directories with random naming patterns.

Security Findings

Suspicious Files Identified

Location: /private/tmp/

• Multiple .dylib files with random hex names (e.g., .18b7f89ef87ffeb4-00000000.dylib)
• Additional .node file: .b8a79ff4cda7eae9-00000001.node
• All .dylib files are approximately 611,936 bytes
• Created over multiple days (Dec 12-19, 2025)
• Currently loaded by active OpenCode processes

File Analysis Results

File 1: libopentui.dylib (as identified in the library)

• Size: 611,936 bytes
• Architecture: ARM64 (Mach-O 64-bit dynamically linked shared library)
• Code Signature: Ad-hoc signed (not trusted)
• Gatekeeper Status: REJECTED by macOS security
• Dependencies:
  • @rpath/libopentui.dylib
  • /usr/lib/libSystem.B.dylib

File 2: .b8a79ff4cda7eae9-00000001.node

• Type: Node.js native addon
• Status: Currently loaded by OpenCode process
• Concern: Native modules have system-level access
• Missing: File was not accessible for detailed analysis during investigation

Security Concerns

1. Unauthorized Code Execution: Untrusted libraries being injected into legitimate processes
2. Evasion Tactics: Random naming in temporary directories to avoid detection
3. Dual Vector Attack: Both .dylib (system library) and .node (Node.js addon) components
4. Persistence: Multiple versions created over time maintaining access
5. Potential Data Exfiltration: Terminal UI library could capture sensitive input
6. Privilege Escalation: Using OpenCode's permissions for malicious activities
7. Native Module Risks: .node files have direct system access and can bypass JavaScript sandbox

Technical Details

The .dylib library contains terminal-related functionality:

• Terminal rendering capabilities
• True color support
• FPS monitoring
• Terminal capability queries

The .node file represents a native Node.js addon with system-level access capabilities.

However, the ad-hoc signature, Gatekeeper rejection, and native module loading indicate these are not properly vetted components and pose significant security risks.

Evidence

# Process loading suspicious files
lsof -p [opencode_pid] | grep -E "(\.dylib|\.node)"
# Shows: 
# /private/tmp/.18b7f89ef87ffeb4-00000000.dylib
# /private/tmp/.b8a79ff4cda7eae9-00000001.node

# Gatekeeper rejection for .dylib
spctl -a -v /private/tmp/.18b7f89ef87ffeb4-00000000.dylib
# Result: rejected

# Code signature issues
codesign -dv /private/tmp/.18b7f89ef87ffeb4-00000000.dylib
# Shows: Signature=adhoc, TeamIdentifier=not set

Questions for Maintainers

1. Are these temporary libraries official components of OpenCode?
2. Why are they using ad-hoc signatures instead of proper code signing?
3. What is the purpose of creating multiple versions in temp directories?
4. Can you verify the legitimacy of both libopentui.dylib and the .node file?
5. Why does OpenCode need to load native Node.js addons from temporary directories?
6. What security controls are in place for dynamically loaded native modules?

Recommendations

1. Immediate: Verify if these are legitimate components
2. Short-term: Implement proper code signing for all libraries
3. Long-term: Consider security audit of all loaded components
4. Documentation: Clearly document all third-party dependencies

Environment

• OS: macOS
• OpenCode Version: Latest (installed via npm)
• Architecture: ARM64 (Apple Silicon)

Security Impact

This represents a medium to high security risk due to:

• Untrusted code execution in user context
• Potential for data interception
• Possibility of persistence mechanisms

I recommend immediate investigation to determine if this is:

• Intended behavior (with poor security practices)
• A compromised build process
• Malicious injection via legitimate software

Please advise on the security status of these components and recommended user actions.

[github-actions[bot]]

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

• #5175: can not start opencode on ubuntu /tmp does not allow execution of .so
• #4605: OpenTUI appears to not be respecting setting TMPDIR when starting up, leading to failure to initialize OpenTUI library
• #3765: Failed to initialize OpenTUI render library: Failed to open library

While your issue frames these as security concerns about suspicious libraries, the underlying root cause appears to be the OpenTUI rendering library (libopentui) being extracted to temporary directories with security-restricted permissions. These other issues document the same library loading behavior from different perspectives (permissions/TMPDIR issues).

Feel free to ignore if your security concerns address aspects beyond the temporary library loading behavior covered in those issues.

[kommander]

This is how bun uses bundled native lib in a standalone executable, it extracts them to the filesystem and loads them from there. This is normal and expected behaviour. The random naming is to avoid collisions for libs with the same name when multiple versions are installed. There are many opencode releases, multiple a day most of the time, so it may create many versions of these files, which is also normal and expected.

The libopentui.dylib is definitely fine. I am not sure which lib the .node file is, I think we bundle sharp image library. I'll check the .node file, but I am sure that is legit as well.

afaik, bun checks the checksum for the loaded library versions in a standalone executable to make sure it only loads the version it actually extracted and was bundled with.

If something has access to your system to switch out the libs that a bun standalone executable loads, your system is already compromised.