Isolate MCP workspace binding across author/reviewer/merger namespaces #510

New Issue

2026-07-08T02:45:48-05:00

jcwalker3 commented

2026-07-08 02:45:48 -05:00

Problem

Merge/review operations can be blocked because the MCP server resolves active task workspace through a dirty shared author worktree, even when the current role/session is merger or reviewer and the root checkout is clean.

The workspace-purity guard is doing the right thing by blocking mutations from dirty worktrees. The bug is that role-specific MCP namespaces can inherit or bind to the wrong active task workspace across author/reviewer/reconciler/merger boundaries.

Observed case

PR #487 / issue #485 was approved and all merge gates were green, but gitea_merge_pr failed closed because the merger MCP runtime bound workspace purity to:

branches/mcp-author-worktree

That worktree contained foreign author WIP, so the merge gate correctly blocked the merge. The durable issue is cross-role workspace binding/inheritance, not the guard itself.

Acceptance criteria

Author, reviewer, reconciler, and merger namespaces must not inherit each other's active task worktree by default.
GITEA_AUTHOR_WORKTREE must not control reviewer/merger workspace purity unless explicitly intended.
Merger sessions must be able to bind to a clean dedicated merger workspace.
Reviewer sessions must be able to bind to a clean dedicated review workspace under branches/.
If a namespace resolves to a dirty foreign worktree, the error must clearly say:
- which workspace was used
- which environment/config selected it
- how to rebind/reconnect safely
Add tests proving:
- dirty author worktree does not poison merger namespace when merger has its own clean workspace
- dirty author worktree does not poison reviewer namespace when reviewer has its own clean worktree
- dirty workspace still blocks mutations when it is actually the active task workspace
- root-control checkout remains protected by #274/#475 rules
Update docs/runbooks to require dedicated branches/ workspaces for reviewer and merger mutations.

Non-goals

Do not weaken the workspace-purity guard.
Do not allow merging from dirty worktrees.
Do not bypass #274/#475.

Related context

Related but narrower: #503 covers reviewer mutation tools using the active branches worktree instead of stale MCP server process root.
This issue is broader: it requires namespace-scoped workspace binding isolation across author, reviewer, reconciler, and merger runtimes.

## Problem Merge/review operations can be blocked because the MCP server resolves active task workspace through a dirty shared author worktree, even when the current role/session is merger or reviewer and the root checkout is clean. The workspace-purity guard is doing the right thing by blocking mutations from dirty worktrees. The bug is that role-specific MCP namespaces can inherit or bind to the wrong active task workspace across author/reviewer/reconciler/merger boundaries. ## Observed case PR #487 / issue #485 was approved and all merge gates were green, but `gitea_merge_pr` failed closed because the merger MCP runtime bound workspace purity to: ```text branches/mcp-author-worktree ``` That worktree contained foreign author WIP, so the merge gate correctly blocked the merge. The durable issue is cross-role workspace binding/inheritance, not the guard itself. ## Acceptance criteria 1. Author, reviewer, reconciler, and merger namespaces must not inherit each other's active task worktree by default. 2. `GITEA_AUTHOR_WORKTREE` must not control reviewer/merger workspace purity unless explicitly intended. 3. Merger sessions must be able to bind to a clean dedicated merger workspace. 4. Reviewer sessions must be able to bind to a clean dedicated review workspace under `branches/`. 5. If a namespace resolves to a dirty foreign worktree, the error must clearly say: - which workspace was used - which environment/config selected it - how to rebind/reconnect safely 6. Add tests proving: - dirty author worktree does not poison merger namespace when merger has its own clean workspace - dirty author worktree does not poison reviewer namespace when reviewer has its own clean worktree - dirty workspace still blocks mutations when it is actually the active task workspace - root-control checkout remains protected by #274/#475 rules 7. Update docs/runbooks to require dedicated `branches/` workspaces for reviewer and merger mutations. ## Non-goals - Do not weaken the workspace-purity guard. - Do not allow merging from dirty worktrees. - Do not bypass #274/#475. ## Related context - Related but narrower: #503 covers reviewer mutation tools using the active branches worktree instead of stale MCP server process root. - This issue is broader: it requires namespace-scoped workspace binding isolation across author, reviewer, reconciler, and merger runtimes.

jcwalker3 added the status:in-progress label 2026-07-08 02:52:28 -05:00

jcwalker3 commented

2026-07-08 02:52:28 -05:00

Issue claim heartbeat

kind: claim
issue: Isolate MCP workspace binding across author/reviewer/merger namespaces (#510)
branch: pending
phase: claimed
profile: prgs-author
pr: none
blocker: none
next_action: create worktree and begin implementation

**Issue claim heartbeat** - kind: claim - issue: #510 - branch: pending - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation

jcwalker3 commented

2026-07-08 02:52:52 -05:00

Issue claim heartbeat

kind: progress
issue: Isolate MCP workspace binding across author/reviewer/merger namespaces (#510)
branch: feat/issue-510-workspace-binding-isolation
phase: implementation
profile: prgs-author
pr: none
blocker: none
next_action: lock issue and implement namespace workspace binding

**Issue claim heartbeat** - kind: progress - issue: #510 - branch: feat/issue-510-workspace-binding-isolation - phase: implementation - profile: prgs-author - pr: none - blocker: none - next_action: lock issue and implement namespace workspace binding

jcwalker3 referenced this issue from a commit

2026-07-08 02:57:44 -05:00

feat: isolate MCP workspace binding across role namespaces (Closes #510)

jcwalker3 referenced a pull request that will close this issue

2026-07-08 02:57:50 -05:00

feat: isolate MCP workspace binding across role namespaces (Closes #510) #512

jcwalker3 referenced this issue from a commit

2026-07-08 03:08:13 -05:00

feat: isolate MCP workspace binding across role namespaces (Closes #510)

sysadmin referenced this issue

2026-07-08 03:25:43 -05:00

feat: isolate MCP workspace binding across role namespaces (Closes #510) #512