Context ambiguity in multi-workspace setups

[zikajk]

When a user is working with multiple workspaces (e.g., multiple git worktrees), it is currently unclear which workspace an edited file belongs to.

To resolve this ambiguity, we should expand the context provided in tool calls. Including specific workspace information will make it clear which workspace is being targeted or affected.

[ericdallo]

@zikajk why this is important? what we are losing right now or is not working because of that?

[zikajk]

@ericdallo I don't know if it's really important, but to find out which file is being edited, you have to open it—I don't think you can tell from the ECA itself.
Today was the first day I encountered this issue, so it is unlikely to be a frequent problem.

[ericdallo]

Hum it's still not clear to me why you think that's a problem, actually I don't get what 's happening to the user that could be a proble, why user would care which workspace the file being edited is related?

[zikajk]

A certain change might make sense in one workspace but not in the other, where you definitely don't want it.

[itkonen]

I had a similar problem with worktrees, as I would have liked to open a separate workspace for the new worktree. ECA defaults to multiple workspace roots in the workspace, which is sometimes convenient, but I couldn't open a new workspace for a new worktree. Even after removing the worktrees root from the workspace, the current implementation won't open a new workspace.

So I tried to create a fork with a new command to create a workspace, but I'm not quite sure if this is the right direction, so I didn't open a PR.

But I guess the point is to gain more control over workspaces, so the user can isolate concurrent work on multiple worktrees. One issue is that agents might get confused looking at multiple root folders. Second, some MCP servers operate on the folder in which they were launched, so we need separate workspaces/eca-servers on each worktree folder.