TUI renders blank responses when launched from a symlinked directory #16528

Activity

1. github-actions

   assigned

   rekram1-node

   on Mar 7, 2026
2. github-actions commented on Mar 7, 2026

   

   github-actionsBot

   on Mar 7, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [regression] opencode 1.2.21 freezes on session start if the current working directory is a symlink #16522: Same root cause — CWD is a symlink causes opencode to misbehave in v1.2.21, with an identical analysis pointing to thread.ts and even a proposed fix
   • Two server instances created when project path contains symlink, causing TUI to freeze on prompt #15482: Same underlying problem — two separate instances created when working directory is a symlink, causing TUI to not display responses/freeze on prompts

   Please review those issues and consider closing this one if they cover your case, or add any additional context that differs.
3. cristianmiranda

   added a commit that references this issue on Mar 7, 2026

   fix: resolve TUI blank response when launched from symlinked directory

   ...

   This issue will close once commit d1fd8d4 is merged into the 'dev' branch.

   d1fd8d4
4. mindcrime commented on Mar 8, 2026

   

   mindcrime

   on Mar 8, 2026

   More actions

   FWIW, I'm experiencing what appears to be the same issue, BUT... in my case, the presence of absence of a Git repo makes no difference in the OpenCode behavior. I simply see the case where:

   1. If I launch OpenCode from a symlinked directory, responses are not rendered in the session (but if you exit out and then resume the session, it appears that those responses are in the session history)
   2. If I launch OpenCode in the same directory, but using the real path, it works fine.

   This is all on PopOS 22.04 LTS and using OpenCode 1.2.21.

   👍React with 👍3Reacted by Cristian Miranda, Santiago M. Mola and cfchou
5. cristianmiranda commented on Mar 8, 2026

   

   cristianmiranda

   on Mar 8, 2026

   Author

   More actions

   FWIW, I'm experiencing what appears to be the same issue, BUT... in my case, the presence of absence of a Git repo makes no difference in the OpenCode behavior. I simply see the case where:

   1. If I launch OpenCode from a symlinked directory, responses are not rendered in the session (but if you exit out and then resume the session, it appears that those responses are in the session history)
   2. If I launch OpenCode in the same directory, but using the real path, it works fine.

   This is all on PopOS 22.04 LTS and using OpenCode 1.2.21.

   Looks like this fix would cover that exact scenario 🙌🏽
6. prolific commented on Mar 8, 2026

   

   prolific

   on Mar 8, 2026

   More actions

   Yes, I am also facing exactly the same issue where not seeing any responses in TUI when opened inside symlinked directory.
7. jyapayne commented on Mar 8, 2026

   

   jyapayne

   on Mar 8, 2026

   More actions

   I am also facing the same issue. In this case, I am on Aurora Linux, which symlinks the entire home directory, so opencode doesn't work anywhere.

   Here is some more info:

   Bug Description

   On Fedora Atomic desktops (Silverblue, Aurora, Bazzite, etc.), /home is a symlink to /var/home. Starting in v1.2.21, the TUI renders blank assistant responses — the agent header appears but no response text is shown. The backend works correctly (LLM responses are received and stored in the database).

   Root Cause

   The v1.2.21 changes to thread.ts and server.ts introduced Filesystem.resolve() for directory path handling. On Linux, Filesystem.resolve() calls path.resolve(), which does not follow symlinks. This creates a path mismatch:

   • process.env.PWD = /home/joey (the symlink path, set by the shell)
   • process.cwd() = /var/home/joey (the real path, because the kernel resolves symlinks on chdir)

   In thread.ts (line 114):

   const root = Filesystem.resolve(process.env.PWD ?? process.cwd())
   // → path.resolve("/home/joey") → "/home/joey"

   This /home/joey path is passed as directory to the SDK client, which sends it as the x-opencode-directory header. But elsewhere in the server pipeline, process.cwd() returns /var/home/joey, causing a mismatch between the TUI's directory context and the server's instance directory. Events are published under one path but the TUI is listening under the other.

   Reproduction

   1. Use any Linux distro where /home is a symlink (e.g., Fedora Atomic: /home → var/home)
   2. Run opencode v1.2.21
   3. Send any message
   4. The agent header appears but the response text is blank
   5. The response IS stored in the sqlite database — only the TUI rendering fails

   Workarounds

   • Set PWD to the real path: PWD=/var/home/joey opencode works
   • Add export PWD=$(realpath "$PWD") to shell rc
   • Downgrade to v1.2.20

   Suggested Fix

   Filesystem.resolve() on Linux should follow symlinks (e.g., use fs.realpathSync) rather than just path.resolve(), which only normalizes path segments without resolving symlinks. Alternatively, thread.ts could use process.cwd() instead of process.env.PWD since process.cwd() always returns the canonical path.

   Version Info

   • Works: v1.2.20
   • Broken: v1.2.21
   • Platform: Fedora Aurora 43 (Fedora Atomic), Linux 6.18.7
   • Terminals tested: Ghostty 1.2.3, Ptyxis (both affected)

   Bisection

   The regression was introduced in the v1.2.20→v1.2.21 release. The relevant commits that changed path handling:

   • server.ts: Added Filesystem.resolve() wrapper around directory in middleware
   • thread.ts: Changed process.env.PWD ?? process.cwd() to Filesystem.resolve(process.env.PWD ?? process.cwd())
   • instance.ts: Added Filesystem.resolve(input.directory) in Instance.provide()
8. cristianmiranda commented on Mar 8, 2026

   

   cristianmiranda

   on Mar 8, 2026

   Author

   More actions

   I am also facing the same issue. In this case, I am on Aurora Linux, which symlinks the entire home directory, so opencode doesn't work anywhere.

   Here is some more info:

   Bug Description

   On Fedora Atomic desktops (Silverblue, Aurora, Bazzite, etc.), /home is a symlink to /var/home. Starting in v1.2.21, the TUI renders blank assistant responses — the agent header appears but no response text is shown. The backend works correctly (LLM responses are received and stored in the database).

   Root Cause

   The v1.2.21 changes to thread.ts and server.ts introduced Filesystem.resolve() for directory path handling. On Linux, Filesystem.resolve() calls path.resolve(), which does not follow symlinks. This creates a path mismatch:

   • process.env.PWD = /home/joey (the symlink path, set by the shell)
   • process.cwd() = /var/home/joey (the real path, because the kernel resolves symlinks on chdir)

   In thread.ts (line 114):

   const root = Filesystem.resolve(process.env.PWD ?? process.cwd())
   // → path.resolve("/home/joey") → "/home/joey"

   This /home/joey path is passed as directory to the SDK client, which sends it as the x-opencode-directory header. But elsewhere in the server pipeline, process.cwd() returns /var/home/joey, causing a mismatch between the TUI's directory context and the server's instance directory. Events are published under one path but the TUI is listening under the other.

   Reproduction

   1. Use any Linux distro where /home is a symlink (e.g., Fedora Atomic: /home → var/home)
   2. Run opencode v1.2.21
   3. Send any message
   4. The agent header appears but the response text is blank
   5. The response IS stored in the sqlite database — only the TUI rendering fails

   Workarounds

   • Set PWD to the real path: PWD=/var/home/joey opencode works
   • Add export PWD=$(realpath "$PWD") to shell rc
   • Downgrade to v1.2.20

   Suggested Fix

   Filesystem.resolve() on Linux should follow symlinks (e.g., use fs.realpathSync) rather than just path.resolve(), which only normalizes path segments without resolving symlinks. Alternatively, thread.ts could use process.cwd() instead of process.env.PWD since process.cwd() always returns the canonical path.

   Version Info

   • Works: v1.2.20
   • Broken: v1.2.21
   • Platform: Fedora Aurora 43 (Fedora Atomic), Linux 6.18.7
   • Terminals tested: Ghostty 1.2.3, Ptyxis (both affected)

   Bisection

   The regression was introduced in the v1.2.20→v1.2.21 release. The relevant commits that changed path handling:

   • server.ts: Added Filesystem.resolve() wrapper around directory in middleware
   • thread.ts: Changed process.env.PWD ?? process.cwd() to Filesystem.resolve(process.env.PWD ?? process.cwd())
   • instance.ts: Added Filesystem.resolve(input.directory) in Instance.provide()

   You can try out the fix in my PR and see how that goes.
9. Hona

   closed this as completedin #16641on Mar 8, 2026