TUI referencing local directory when using attach --dir to connect to a remote server. #3474

Open
opened 2026-02-16 17:40:15 -05:00 by yindo · 4 comments
Owner

Originally created by @jeremytondo on GitHub (Dec 11, 2025).

Originally assigned to: @rekram1-node on GitHub.

Description

I'm testing out a setup where I have the opencode server running on my remote workstation while attaching to it running the TUI on my local Mac laptop (this is an incredible feature btw).

When running opencode attach <url> --dir ~/path/to/project/ it attempts to use a directory on the local machine instead of the remote machine. I'm not sure if this is the intended behavior or not, but I was assuming the server would be the source of truth and look for directories there.

OpenCode version

1.0.146 (both client and server)

Steps to reproduce

  1. Start the server on a remote machine opencode serve --hostname 0.0.0.0
  2. On the local machine attach using the --dir flag opencode attach <url> --dir ~/path/to/project/

Current behavior
Tries to connect to a directory on the local machine.

Expected behavior
TUI opens using the project located at the --dir path on the remote server.

Screenshot and/or share link

No response

Operating System

Remote Host: Arch Linux, Local: MacOS 26.1

Terminal

Ghostty

Originally created by @jeremytondo on GitHub (Dec 11, 2025). Originally assigned to: @rekram1-node on GitHub. ### Description I'm testing out a setup where I have the opencode server running on my remote workstation while attaching to it running the TUI on my local Mac laptop (this is an incredible feature btw). When running `opencode attach <url> --dir ~/path/to/project/` it attempts to use a directory on the local machine instead of the remote machine. I'm not sure if this is the intended behavior or not, but I was assuming the server would be the source of truth and look for directories there. ### OpenCode version 1.0.146 (both client and server) ### Steps to reproduce 1. Start the server on a remote machine `opencode serve --hostname 0.0.0.0` 2. On the local machine attach using the --dir flag `opencode attach <url> --dir ~/path/to/project/` **Current behavior** Tries to connect to a directory on the local machine. **Expected behavior** TUI opens using the project located at the --dir path on the remote server. ### Screenshot and/or share link _No response_ ### Operating System Remote Host: Arch Linux, Local: MacOS 26.1 ### Terminal Ghostty
yindo added the bug label 2026-02-16 17:40:15 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Dec 11, 2025):

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

  • #4686: TUI sends absolute local paths causing ENOENT on server side (Windows client to Linux server path resolution)
  • #4967: opencode attach: File path duplicates client's relative directory, causing ENOENT (similar attach path duplication issue)

Both issues describe problems with path resolution when using remote servers with attach, where paths are resolved on the client instead of the server. Feel free to ignore if this addresses a specific case not covered by those issues.

@github-actions[bot] commented on GitHub (Dec 11, 2025): This issue might be a duplicate of existing issues. Please check: - #4686: TUI sends absolute local paths causing ENOENT on server side (Windows client to Linux server path resolution) - #4967: `opencode attach`: File path duplicates client's relative directory, causing ENOENT (similar attach path duplication issue) Both issues describe problems with path resolution when using remote servers with `attach`, where paths are resolved on the client instead of the server. Feel free to ignore if this addresses a specific case not covered by those issues.
Author
Owner

@jeremytondo commented on GitHub (Dec 11, 2025):

The related issues identified by the bot are likely related, but neither deals with using the attach --dir flag, so it may be worthwhile to keep this open? That is, if this is truly not the expected behavior.

@jeremytondo commented on GitHub (Dec 11, 2025): The related issues identified by the bot are likely related, but neither deals with using the attach --dir flag, so it may be worthwhile to keep this open? That is, if this is truly not the expected behavior.
Author
Owner

@terwey commented on GitHub (Dec 15, 2025):

I have noticed the same behavior. You can reference files in the remote server but it then throws errors as it prefixes it with the local dir.

Also the attach needs serious work because the slightest error on the server and it just perma-hangs on a blank screen with zero indication to the user what it got stuck on.

@terwey commented on GitHub (Dec 15, 2025): I have noticed the same behavior. You can reference files in the remote server but it then throws errors as it prefixes it with the local dir. Also the attach needs serious work because the slightest error on the server and it just perma-hangs on a blank screen with zero indication to the user what it got stuck on.
Author
Owner

@cgarrot commented on GitHub (Jan 9, 2026):

I'm experiencing this issue and wanted to provide some context about when this happens:

General Use Case: Remote Server + Local Client
When OpenCode server runs on a remote machine (VPS, remote workstation, container) and you attach from a local machine:

Current behavior:

# On local machine
opencode attach http://remote-server:4096 --dir /path/to/project
# Bug: The --dir path is interpreted as LOCAL machine path
# Server receives: /local/user/path/to/project (doesn't exist on remote)
# Result: Wrong directory, or connection fails

Expected behavior:

# On local machine
opencode attach http://remote-server:4096 --dir /path/to/project
# Should work as: Send directory path to server
# Server receives: /remote/server/path/to/project (exists on remote)
# Server does: chdir /remote/server/path/to/project
# Result: Opens in correct remote directory

Why this matters:

  1. Multi-project development: Developers work on multiple projects on a remote machine
  2. Fixed server directory: Server starts in a default directory (e.g., /home/user or /workspace)
  3. Remote-first setup: The server is the source of truth, not the local machine

Common scenarios affected:

  • SSH tunnels to remote OpenCode servers
  • Containerized OpenCode instances
  • Development on remote workstations
@cgarrot commented on GitHub (Jan 9, 2026): I'm experiencing this issue and wanted to provide some context about when this happens: **General Use Case: Remote Server + Local Client** When OpenCode server runs on a remote machine (VPS, remote workstation, container) and you attach from a local machine: **Current behavior:** ```bash # On local machine opencode attach http://remote-server:4096 --dir /path/to/project # Bug: The --dir path is interpreted as LOCAL machine path # Server receives: /local/user/path/to/project (doesn't exist on remote) # Result: Wrong directory, or connection fails ``` Expected behavior: ```bash # On local machine opencode attach http://remote-server:4096 --dir /path/to/project # Should work as: Send directory path to server # Server receives: /remote/server/path/to/project (exists on remote) # Server does: chdir /remote/server/path/to/project # Result: Opens in correct remote directory ``` Why this matters: 1. Multi-project development: Developers work on multiple projects on a remote machine 2. Fixed server directory: Server starts in a default directory (e.g., /home/user or /workspace) 3. Remote-first setup: The server is the source of truth, not the local machine Common scenarios affected: - SSH tunnels to remote OpenCode servers - Containerized OpenCode instances - Development on remote workstations
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3474