Create session with a different root/working directory #806

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

Originally created by @Kunde21 on GitHub (Jul 19, 2025).

Originally assigned to: @thdxr on GitHub.

Background:

I'm working in a go mono-repo with multiple services:

/root
  .git
  go.mod
  /protobuf
    /definitions...
  /serviceA
    /handlers
    /businessLogic
    /externalDeps
  /serviceB 
    /handlers
    /businessLogic
    /externalDeps
  /commonlibs
    /logger
    /server
...

Plan

Open opencode in the /root directory
Spin up a session for /root/serviceA to implement a gRPC service.
Spin up another session for /root/serviceB to implement the gRPC client integration.
Use a third session for /root to run an acceptance test, since both will be in the agent's "view".

Outcome

The two sessions begin building independently.
Both make edits and get to a go build/test step, run go build ./... from the /root directory
Both builds find the same problems, some in each area of the code being worked
Agents start competing to edit the same code until I stop one (or both)

Question/Suggestion

Is there a clean way to set up this pair of agents without them getting in a code fight?
Can I do something like the aider --subtree-only option, but still allow read-only access to the rest of the repo?
Is there a way to change where the build/test tooling is executed within the session?

Originally created by @Kunde21 on GitHub (Jul 19, 2025). Originally assigned to: @thdxr on GitHub. ### Background: I'm working in a go mono-repo with multiple services: ``` /root .git go.mod /protobuf /definitions... /serviceA /handlers /businessLogic /externalDeps /serviceB /handlers /businessLogic /externalDeps /commonlibs /logger /server ... ``` ### Plan Open opencode in the `/root` directory Spin up a session for `/root/serviceA` to implement a gRPC service. Spin up another session for `/root/serviceB` to implement the gRPC client integration. Use a third session for `/root` to run an acceptance test, since both will be in the agent's "view". ### Outcome The two sessions begin building independently. Both make edits and get to a go build/test step, run `go build ./...` from the `/root` directory Both builds find the same problems, some in each area of the code being worked Agents start competing to edit the same code until I stop one (or both) ### Question/Suggestion Is there a clean way to set up this pair of agents without them getting in a code fight? Can I do something like the aider `--subtree-only` option, but still allow read-only access to the rest of the repo? Is there a way to change where the build/test tooling is executed within the session?
Author
Owner

@ansh commented on GitHub (Jul 26, 2025):

Would the best way to implement this be to move the cwd from App to Session? @thdxr

I would like to implement it

@ansh commented on GitHub (Jul 26, 2025): Would the best way to implement this be to move the `cwd` from `App` to `Session`? @thdxr I would like to implement it
Author
Owner

@ariedov commented on GitHub (Sep 10, 2025):

I would really like that. My use case is that I have a subagent for managing my notes, which are located in a different directory. Allowing it to change the directory into the "vault" would make it much less error-prone.

@ariedov commented on GitHub (Sep 10, 2025): I would really like that. My use case is that I have a subagent for managing my notes, which are located in a different directory. Allowing it to change the directory into the "vault" would make it much less error-prone.
Author
Owner

@taqtiqa-mark commented on GitHub (Sep 28, 2025):

Is there a clean way to set up this pair of agents without them getting in a code fight?

I wonder if the idiomatic way to achieve this won't (eventually) be via shared sessions?

My use case might be slightly different, in that I encapsulate opencode in a rootless container (podman runtime). This involves some overhead that you tradeoff for some security.

In a scenario such as yours I have /root/ServiceA and /root/ServiceB running in a separate containers (both mounted to /app in their respective containers) with the TUI attached to a common server (http://127.0.0.1:4096).
Ideally they should be able to share sessions with each other across the isolated (container) network.
But right now selfhosted shared sessions appear to be only for enterprise?
https://opencode.ai/docs/share#for-enterprises

@taqtiqa-mark commented on GitHub (Sep 28, 2025): > Is there a clean way to set up this pair of agents without them getting in a code fight? I wonder if the idiomatic way to achieve this won't (eventually) be via shared sessions? My use case might be slightly different, in that I encapsulate opencode in a rootless container (podman runtime). This involves some overhead that you tradeoff for some security. In a scenario such as yours I have `/root/ServiceA` and `/root/ServiceB` running in a separate containers (both mounted to /app in their respective containers) with the TUI attached to a common server (http://127.0.0.1:4096). Ideally they should be able to share sessions with each other across the isolated (container) network. But right now selfhosted shared sessions appear to be only for enterprise? https://opencode.ai/docs/share#for-enterprises
Author
Owner

@R44VC0RP commented on GitHub (Jan 25, 2026):

This is actively being addressed in PR #9365 which adds per-session working directory support via Session.directory.get()/.set() methods.

Once merged, you'll be able to spin up sessions with different root directories for /serviceA, /serviceB, etc.

Keeping this open as the tracking issue.

@R44VC0RP commented on GitHub (Jan 25, 2026): This is actively being addressed in **PR #9365** which adds per-session working directory support via `Session.directory.get()`/`.set()` methods. Once merged, you'll be able to spin up sessions with different root directories for `/serviceA`, `/serviceB`, etc. Keeping this open as the tracking issue.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#806