Skip to content

add --dir flag to opencode run --attach #7376

Closed

Description

@athal7

opencode attach has a --dir flag to specify the working directory when attaching to a remote server:

opencode attach <url>

Options:
  --dir         directory to run in                                                     [string]

However, opencode run --attach does not expose this flag:

opencode run [message..]

Options:
  --attach      attach to a running opencode server (e.g., http://localhost:4096)       [string]
  # no --dir option

Use Case

I'm building opencode-pilot, a service that polls external sources (Linear, GitHub, etc.) and spawns OpenCode sessions for new issues. When a user runs OpenCode Desktop connected to a global server (worktree="/"), I want spawned sessions to:

  1. Appear in the Desktop UI (requires --attach)
  2. Run in the correct project directory (requires --dir)

Currently I can only achieve one or the other:

# Sessions appear in Desktop, but run in wrong directory (home)
cd ~/projects/my-app && opencode run --attach http://localhost:4096 "fix bug"
# Working directory: /Users/me (wrong!)

# Sessions run in correct directory, but don't appear in Desktop
cd ~/projects/my-app && opencode run "fix bug"  
# Working directory: /Users/me/projects/my-app (correct, but isolated)

Proposed Solution

Add --dir flag to opencode run that gets passed through when --attach is used:

opencode run --attach http://localhost:4096 --dir /path/to/project "fix bug"

The server middleware already supports this via x-opencode-directory header or ?directory= query param, so this should be straightforward to wire up.

Related

Activity

  1. changed the title [-]feat(cli): add --dir flag to `opencode run --attach`[/-] [+]add --dir flag to `opencode run --attach`[/+] on Jan 8, 2026
  2. github-actions commented on Jan 8, 2026

    @github-actions
    Contributor

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

    Feel free to ignore if none of these address your specific case.

  3. ekweible commented on Jan 23, 2026

    @ekweible

    Hey @athal7 I noticed you closed #7378, was that because this issue was fixed elsewhere?

  4. athal7 commented on Jan 23, 2026

    @athal7
    ContributorAuthor

    @ekweible i didn't have a chance to continue to test and it seemed there have been quite a lot of structural changes upstream with workspaces. Didn't want to waste reviewer time if it was possibly stale

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions