Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 73 Pull Requests 9 Actions Packages Projects Releases Wiki Activity

Cross-repository MCP workspace binding fails because canonical repo root is derived from script location #706

New Issue
Open
opened 2026-07-13 21:01:07 -05:00 by jcwalker3 · 1 comment
jcwalker3 commented 2026-07-13 21:01:07 -05:00
Owner
Copy Link
Copy Source

Problem

The Gitea-Tools MCP server blocks cross-repository namespaces (like eagenda-author) because it derives the canonical_repo_root from the MCP script's execution path rather than the configured workspace binding.

When validating author mutations in a cross-repository namespace, the mutation guards (assess_workspace_repo_membership and assess_author_mutation_worktree) assume the task workspace must belong to the same .git directory as the Gitea-Tools installation (PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))). This permanently blocks mutations for external repositories.

Reproduction

  1. Define an MCP server namespace (e.g. eagenda-author) in mcp_config.json running the Gitea-Tools server script, but with cwd and target repository set to an external project (e.g. eAgenda).
  2. Authenticate the namespace correctly.
  3. Attempt to create an issue. The Branches-only mutation guard will block the operation, failing the repository membership and branches/ path assertions because they are evaluated against the Gitea-Tools root instead of the eAgenda root.

Acceptance Criteria

  1. Separate the concepts of immutable code/install root (PROJECT_ROOT) and namespace-specific repository workspace root (process_project_root / canonical repo root).
  2. Explicitly configure namespace-scoped workspace binding (e.g. via cwd or environment variables) so that the MCP server correctly identifies the target repository.
  3. Validate that the workspace belongs to the intended target repository, not necessarily the code installation root.
  4. Enforce the branches-only mutation guard inside the target repository.
  5. Fail closed for missing, conflicting, or forged bindings.
  6. Provide simultaneous isolation of prgs and mdcps (or other remote) namespaces.
  7. Add regression tests using two distinct repositories/worktrees to prove cross-repository bindings work safely.
  8. Ensure no weakening of the root-checkout, remote/repository, or anti-stomp guards.

Downstream Blocker

This defect currently blocks the eAgenda document-management reconciliation task, which depends on a functioning eagenda-author namespace.

Related Context

  • Does not overlap with #510 (intra-repository role isolation) or #672 (IDE config sync).
## Problem The Gitea-Tools MCP server blocks cross-repository namespaces (like `eagenda-author`) because it derives the `canonical_repo_root` from the MCP script's execution path rather than the configured workspace binding. When validating author mutations in a cross-repository namespace, the mutation guards (`assess_workspace_repo_membership` and `assess_author_mutation_worktree`) assume the task workspace must belong to the same `.git` directory as the Gitea-Tools installation (`PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))`). This permanently blocks mutations for external repositories. ## Reproduction 1. Define an MCP server namespace (e.g. `eagenda-author`) in `mcp_config.json` running the Gitea-Tools server script, but with `cwd` and target repository set to an external project (e.g. `eAgenda`). 2. Authenticate the namespace correctly. 3. Attempt to create an issue. The Branches-only mutation guard will block the operation, failing the repository membership and `branches/` path assertions because they are evaluated against the Gitea-Tools root instead of the eAgenda root. ## Acceptance Criteria 1. Separate the concepts of immutable code/install root (`PROJECT_ROOT`) and namespace-specific repository workspace root (`process_project_root` / canonical repo root). 2. Explicitly configure namespace-scoped workspace binding (e.g. via `cwd` or environment variables) so that the MCP server correctly identifies the target repository. 3. Validate that the workspace belongs to the intended target repository, not necessarily the code installation root. 4. Enforce the branches-only mutation guard inside the target repository. 5. Fail closed for missing, conflicting, or forged bindings. 6. Provide simultaneous isolation of `prgs` and `mdcps` (or other remote) namespaces. 7. Add regression tests using two distinct repositories/worktrees to prove cross-repository bindings work safely. 8. Ensure no weakening of the root-checkout, remote/repository, or anti-stomp guards. ## Downstream Blocker This defect currently blocks the eAgenda document-management reconciliation task, which depends on a functioning `eagenda-author` namespace. ## Related Context - Does not overlap with #510 (intra-repository role isolation) or #672 (IDE config sync).
jcwalker3 added the type:bug label 2026-07-13 21:01:07 -05:00
jcwalker3 commented 2026-07-14 00:02:54 -05:00
Author
Owner
Copy Link
Copy Source

Canonical Issue State

STATE: Blocked
WHO_IS_NEXT: user
NEXT_ACTION: Fix cross-repository workspace binding logic in namespace_workspace_binding.py or gitea_mcp_server.py.
NEXT_PROMPT:

Resume the Gitea-Tools workspace binding fix for Issue #706.

WHAT_HAPPENED: The eAgenda umbrella and eight child issues remain blocked. Downstream eAgenda validation showed that the native eagenda-author daemon restarted correctly on current master with identity 913443 / mdcps-author and required read/create/comment capabilities. The MCP cwd points to the clean eAgenda author worktree. However, runtime_context still reports both canonical_repository_root and active_task_workspace_root as /Users/jasonwalker/Development/Gitea-Tools.
WHY: The hardcoded workspace binding logic persists on the current deployed master, proving this is not stale-process or client-configuration residue.
RELATED_PRS: N/A
BLOCKERS: Gitea-Tools MCP server is resolving the workspace root based on the script directory rather than the passed cwd. Unblock condition: The server must successfully parse the MCP client's cwd and bind active_task_workspace_root to it.
VALIDATION: gitea_whoami and gitea_get_runtime_context were called natively on the eagenda-author server; no direct API, CLI bypass, process kill, or cross-project patch was attempted.
LAST_UPDATED_BY: Antigravity AI

## Canonical Issue State STATE: Blocked WHO_IS_NEXT: user NEXT_ACTION: Fix cross-repository workspace binding logic in `namespace_workspace_binding.py` or `gitea_mcp_server.py`. NEXT_PROMPT: ```text Resume the Gitea-Tools workspace binding fix for Issue #706. ``` WHAT_HAPPENED: The eAgenda umbrella and eight child issues remain blocked. Downstream eAgenda validation showed that the native `eagenda-author` daemon restarted correctly on current master with identity `913443` / `mdcps-author` and required read/create/comment capabilities. The MCP `cwd` points to the clean eAgenda author worktree. However, `runtime_context` still reports both `canonical_repository_root` and `active_task_workspace_root` as `/Users/jasonwalker/Development/Gitea-Tools`. WHY: The hardcoded workspace binding logic persists on the current deployed master, proving this is not stale-process or client-configuration residue. RELATED_PRS: N/A BLOCKERS: Gitea-Tools MCP server is resolving the workspace root based on the script directory rather than the passed `cwd`. Unblock condition: The server must successfully parse the MCP client's cwd and bind active_task_workspace_root to it. VALIDATION: `gitea_whoami` and `gitea_get_runtime_context` were called natively on the `eagenda-author` server; no direct API, CLI bypass, process kill, or cross-project patch was attempted. LAST_UPDATED_BY: Antigravity AI
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
allocator
Controller-owned work allocator
 anti-stomp
Prevent concurrent LLM session stomping
 architecture
Architecture / structural design
 bug
chore
codex
OpenAI Codex client / workflow session surface
 concurrency
Concurrent session safety
 contamination
Workflow or session contamination incident
 control-plane
MCP control-plane coordination and allocation authority
 dashboard
MCP operational dashboard/queue view
 database
Internal coordination storage (SQLite/Postgres)
 design
Design / investigation, no implementation
 documentation
Docs / runbooks
 enhancement
New feature or improvement
 gitea
Gitea MCP workflow
 glitchtip
GlitchTip integration
 important
incident
Operational or process incident requiring durable audit trail
 incident-bridge
Sentry-to-Gitea incident bridging
 integration
Integration testing
 jenkins
Jenkins integration
 labels
Label taxonomy management
 leases
Lease adopt/release/expire lifecycle
 mcp
MCP server / tooling
 mcp-health
MCP namespace and runtime health
 mcp-menu
MCP menu surface
 multi-project
Work spanning multiple monitoring projects or Gitea repos
 mutating
Mutating action; requires gating
 nice-to-have
observability
Observability, metrics, traces, error reporting
 portability
Cross-platform / portability
 preflight
Shared preflight gates before mutation
 protected-branch
Protected branch / stable-branch policy concern
 queue
Work queue visibility and allocation
 read-only
Read-only, no mutation
 reconnect
MCP client reconnect/reload recovery path
 recovery
Recovery paths for stale/foreign leases
 refactor
Code refactor / restructure
 release
Release / versioning
 reliability
Reliability / failure handling
 resumable-review
Persist and resume prepared review verdicts across sessions
 reviewer
Reviewer workflow tooling
 roadmap
Roadmap / umbrella issue
 safety
Safety rails and fail-closed mutation guards
 security
Security / trust boundary
 self-hosted
Self-hosted infrastructure integration
 sentry
Sentry error monitoring integration
 stale-runtime
Stale backend daemon / runtime-vs-master parity failures
 status:blocked
Issue is blocked
 status:in-progress
Issue is being worked on
 status:pr-open
Issue has an open pull request
 status:ready
Issue is ready for work
 terminal-lock
Terminal review lock (#332) path
 testing
Tests / test coverage
 tracker
Issue tracker hygiene / meta
 type:bug
Bug or defect
 type:feature
Feature or enhancement
 type:feature
Feature or enhancement
 type:guardrail
Safety gate or guardrail
 visibility
Workflow state visibility for LLMs/operators
 workflow
Cross-tool workflow
 workflow-hardening
LLM workflow coordination hardening
 workflow-hardening
LLM workflow coordination hardening
No labels type:bug
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#706