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

Gitea MCP namespaces returned Transport closed; recovered via host auto-reconnect at session startup #584

New Issue
Open
opened 2026-07-09 12:02:37 -05:00 by jcwalker3 · 5 comments
jcwalker3 commented 2026-07-09 12:02:37 -05:00
Owner
Copy Link
Copy Source

Problem (prior session)

Both Gitea MCP namespaces failed with Transport closed, blocking all Gitea work (issue comments, PR creation, reviews, merges). Known failing checks:

  • gitea-author.gitea_whoami(remote="prgs") → Transport closed
  • gitea-reviewer.gitea_whoami(remote="prgs") → Transport closed

Recovery action

No manual restart was issued. The MCP host/client auto-reconnected all four namespaces at session startup (gitea-tools/author, gitea-reviewer, gitea-merger, gitea-reconciler) before the first tool call. Recovery was verify-only; no raw API, no process killing, no temp scripts, no MCP internals, no in-memory restoration.

Process evidence (read-only ps)

22 mcp_server.py processes across age cohorts:

  • LIVE cohort — pids 22277–22284 (~36 min, spawned this session). Reviewer proof reports session_pid=22284 / writer_pid=22284, inside this cohort.
  • 14 stale orphans from prior sessions/reconnects: pids 27037/27038/27069/27070 (~33m), 57283–57284 (~20m), 80629/80631 (~9m), 92550/92551 (~3.5m), 95670/95675/95793/95794 (~2.5m).

Stale orphans are not bound to the client stdio pipes — the live cohort answered both namespaces cleanly on the first call, so the orphans hold no transport. They idle. Recommend an operator sweep to reclaim them; not killed here (process-kill not operator-authorized).

Verification (run twice, stable)

Check Round 1 Round 2
gitea-author.gitea_whoami(prgs) PASS — jcwalker3, profile prgs-author PASS
gitea-reviewer.gitea_whoami(prgs) PASS — sysadmin, profile prgs-reviewer PASS
gitea-author.gitea_resolve_task_capability(comment_issue) PASS — allowed_in_current_session: true, restart_required: false PASS
gitea-reviewer.gitea_resolve_task_capability(review_pr) PASS — allowed_in_current_session: true, boundary_clean: true PASS

Outcome

Gitea MCP runtime healthy on both author and reviewer namespaces. Normal Gitea-Tools workflows may resume.

Note on #556

The original recovery task pointed at Issue #556, but #556 is closed and documents a different fault — run_terminal_command IO Error: No such file or directory (os error 2) (terminal launcher), not MCP Transport closed. Per operator direction, this evidence was filed as a new issue instead of mislabeling the closed terminal-launcher tracker.

## Problem (prior session) Both Gitea MCP namespaces failed with `Transport closed`, blocking all Gitea work (issue comments, PR creation, reviews, merges). Known failing checks: * `gitea-author.gitea_whoami(remote="prgs")` → `Transport closed` * `gitea-reviewer.gitea_whoami(remote="prgs")` → `Transport closed` ## Recovery action No manual restart was issued. The MCP host/client **auto-reconnected all four namespaces at session startup** (`gitea-tools`/author, `gitea-reviewer`, `gitea-merger`, `gitea-reconciler`) before the first tool call. Recovery was verify-only; no raw API, no process killing, no temp scripts, no MCP internals, no in-memory restoration. ## Process evidence (read-only `ps`) 22 `mcp_server.py` processes across age cohorts: * **LIVE cohort** — pids 22277–22284 (~36 min, spawned this session). Reviewer proof reports `session_pid=22284` / `writer_pid=22284`, inside this cohort. * **14 stale orphans** from prior sessions/reconnects: pids 27037/27038/27069/27070 (~33m), 57283–57284 (~20m), 80629/80631 (~9m), 92550/92551 (~3.5m), 95670/95675/95793/95794 (~2.5m). Stale orphans are **not bound to the client stdio pipes** — the live cohort answered both namespaces cleanly on the first call, so the orphans hold no transport. They idle. Recommend an operator sweep to reclaim them; not killed here (process-kill not operator-authorized). ## Verification (run twice, stable) | Check | Round 1 | Round 2 | |---|---|---| | `gitea-author.gitea_whoami(prgs)` | PASS — `jcwalker3`, profile `prgs-author` | PASS | | `gitea-reviewer.gitea_whoami(prgs)` | PASS — `sysadmin`, profile `prgs-reviewer` | PASS | | `gitea-author.gitea_resolve_task_capability(comment_issue)` | PASS — `allowed_in_current_session: true`, `restart_required: false` | PASS | | `gitea-reviewer.gitea_resolve_task_capability(review_pr)` | PASS — `allowed_in_current_session: true`, `boundary_clean: true` | PASS | ## Outcome Gitea MCP runtime healthy on both author and reviewer namespaces. Normal Gitea-Tools workflows may resume. ## Note on #556 The original recovery task pointed at Issue #556, but #556 is **closed** and documents a different fault — `run_terminal_command` `IO Error: No such file or directory (os error 2)` (terminal launcher), not MCP `Transport closed`. Per operator direction, this evidence was filed as a new issue instead of mislabeling the closed terminal-launcher tracker.
jcwalker3 added the mcpgiteaworkflow labels 2026-07-09 12:02:38 -05:00
jcwalker3 commented 2026-07-09 19:09:15 -05:00
Author
Owner
Copy Link
Copy Source

Recurrence — 2026-07-09 (mid-session flap, self-recovered)

New occurrence of the Transport closed failure this issue tracks, with two evidence points that extend the prior report.

What happened

  1. Session start: operator /mcp reconnected all four namespaces (gitea-merger, gitea-reconciler, gitea-reviewer, gitea-tools).
  2. Read proofs on gitea-tools (remote=prgs) all PASSED: gitea_whoami, gitea_get_runtime_context, gitea_get_shell_health.
  3. Next call mcp__gitea-merger__gitea_get_runtime_context returned Error: No such tool available.
  4. Harness confirmed all 312 gitea- tools disconnected* across all four namespaces (merger, reconciler, reviewer, tools).
  5. Moments later, all 312 tools reconnected with no operator action — transient flap. gitea_whoami(prgs) re-verified PASS (jcwalker3 / prgs-author / keychain) after recovery.

New evidence point 1 — flap is not startup-only

Prior report framed recovery as "auto-reconnect at session startup." This occurrence dropped mid-session, between two tool calls, then self-recovered mid-session. So the fault is not confined to the startup handshake; a live, healthy session can lose all four namespaces transiently.

New evidence point 2 — NOT a stale process-root binding

The immediately-prior gitea_get_runtime_context (gitea-tools / prgs-author) proved a clean workspace binding right before the drop:

Field Value
mcp_server_process_root /Users/jasonwalker/Development/Gitea-Tools
active_task_workspace_root /Users/jasonwalker/Development/Gitea-Tools/branches/mcp-author-clean-ns
inspected_git_root /Users/jasonwalker/Development/Gitea-Tools/branches/mcp-author-clean-ns
workspace_roots_aligned true
dirty_files []
master_parity in parity at ae6a3ae, stale=false, restart_required=false

Filesystem cross-check (read-only): author worktree branches/mcp-author-clean-ns is on feat/issue-543-mcp-namespace-health-check, HEAD ebd06b7, clean — matches inspected_git_root exactly. So the mutation-tool workspace was correctly bound to the clean branches/ worktree. The fault is the transport channel closing, not a workspace/process-root binding defect.

Classification

MCP transport closed (EOF-class), transient — self-recovered. No fail-closed gate fired; no server-side mutation occurred during the drop; reads worked up to the moment of disconnect.

Recommended operator action

  • Transient flap needs no manual restart when it self-recovers; re-run gitea_whoami → gitea_resolve_task_capability immediately before any mutation (done here before this comment).
  • If the drop does not self-recover, /mcp reconnect the affected namespaces and follow the client is closing: EOF recovery runbook (commit f83d2c2, issue #543).
  • Consider correlating with #607/#606 (Sentry MCP incident bridge) so these transient EOF flaps are captured automatically rather than only when a controller happens to observe one.
## Recurrence — 2026-07-09 (mid-session flap, self-recovered) New occurrence of the `Transport closed` failure this issue tracks, with two evidence points that extend the prior report. ### What happened 1. Session start: operator `/mcp` reconnected all four namespaces (gitea-merger, gitea-reconciler, gitea-reviewer, gitea-tools). 2. Read proofs on `gitea-tools` (remote=prgs) all PASSED: `gitea_whoami`, `gitea_get_runtime_context`, `gitea_get_shell_health`. 3. Next call `mcp__gitea-merger__gitea_get_runtime_context` returned `Error: No such tool available`. 4. Harness confirmed **all 312 gitea-* tools disconnected** across all four namespaces (merger, reconciler, reviewer, tools). 5. Moments later, **all 312 tools reconnected with no operator action** — transient flap. `gitea_whoami(prgs)` re-verified PASS (jcwalker3 / prgs-author / keychain) after recovery. ### New evidence point 1 — flap is not startup-only Prior report framed recovery as "auto-reconnect **at session startup**." This occurrence dropped **mid-session, between two tool calls**, then self-recovered mid-session. So the fault is not confined to the startup handshake; a live, healthy session can lose all four namespaces transiently. ### New evidence point 2 — NOT a stale process-root binding The immediately-prior `gitea_get_runtime_context` (gitea-tools / prgs-author) proved a **clean** workspace binding right before the drop: | Field | Value | |---|---| | mcp_server_process_root | /Users/jasonwalker/Development/Gitea-Tools | | active_task_workspace_root | /Users/jasonwalker/Development/Gitea-Tools/branches/mcp-author-clean-ns | | inspected_git_root | /Users/jasonwalker/Development/Gitea-Tools/branches/mcp-author-clean-ns | | workspace_roots_aligned | true | | dirty_files | [] | | master_parity | in parity at ae6a3ae, stale=false, restart_required=false | Filesystem cross-check (read-only): author worktree `branches/mcp-author-clean-ns` is on `feat/issue-543-mcp-namespace-health-check`, HEAD ebd06b7, clean — matches `inspected_git_root` exactly. So the mutation-tool workspace was correctly bound to the clean `branches/` worktree. **The fault is the transport channel closing, not a workspace/process-root binding defect.** ### Classification **MCP transport closed (EOF-class), transient — self-recovered.** No fail-closed gate fired; no server-side mutation occurred during the drop; reads worked up to the moment of disconnect. ### Recommended operator action - Transient flap needs no manual restart when it self-recovers; re-run `gitea_whoami` → `gitea_resolve_task_capability` immediately before any mutation (done here before this comment). - If the drop does **not** self-recover, `/mcp reconnect` the affected namespaces and follow the `client is closing: EOF` recovery runbook (commit f83d2c2, issue #543). - Consider correlating with #607/#606 (Sentry MCP incident bridge) so these transient EOF flaps are captured automatically rather than only when a controller happens to observe one.
sysadmin commented 2026-07-12 09:18:39 -05:00
Owner
Copy Link
Copy Source

Canonical Issue State

STATE: open — new reproduction from PR #680 reviewer recovery (transport EOF)
WHO_IS_NEXT: author
NEXT_ACTION: implement typed IDE-namespace EOF recovery + forbid manual server launch as recovery; add regression coverage
NEXT_PROMPT:

Author: extend #584 for client is closing: EOF on gitea-reviewer/gitea-author during review submit. Fail closed on unhealthy client_namespace probe; document IDE reconnect + whoami only; never gitea_mcp_server.py manual launch or pkill. Link #672 config drift and #609 resume. Work in branches/ worktree only.

WHAT_HAPPENED: During PR #680 re-review recovery, a prior session finished local validation at head 3fd02a3 but could not submit APPROVE after gitea-reviewer/gitea-author returned client is closing: EOF. Session also touched Antigravity mcp_config.json (added gitea-author/gitea-reviewer vs backup) and attempted direct server launch. This recovery session verified client-managed gitea-reviewer healthy (sysadmin/prgs-reviewer, master parity in_parity, namespace health healthy) without manual launches or config revert. Extra mcp_server.py daemons still present (~dozens); no gitea_mcp_server.py process now.
WHY: Transport EOF leaves prepared approvals non-canonical; ad-hoc config/process recovery is unsafe and unproven.
RELATED_PRS: #680 (Closes #604); cross-ref #672 #609 #610 #630 #678 #681
BLOCKERS: product gap — no automated typed recovery for IDE EOF during review submit; orphan daemons unreclaimed
VALIDATION: this session client_namespace health healthy; whoami sysadmin/prgs-reviewer; assess_master_parity in_parity @ 22698c1; focused anti-stomp 43 passed at head 3fd02a3; Gitea still shows REQUEST_CHANGES stale on ea8e186 until approval submitted
LAST_UPDATED_BY: sysadmin (prgs-reviewer)

Config delta (no secrets; no auto-revert)

  • Active: ~/.gemini/antigravity-ide/mcp_config.json
  • Backup: mcp_config.json.bak-gitea-repair
  • ADDED vs backup: gitea-author + gitea-reviewer (mcp_server.py, GITEA_MCP_PROFILE prgs-*, GITEA_MCP_CONFIG profiles.json, GITEA_DUMMY=1)
  • Required automated coverage: EOF typed blocker; resume draft after disconnect (#609); active-config drift proof (#672); no pkill/manual launch (#630)
## Canonical Issue State STATE: open — new reproduction from PR #680 reviewer recovery (transport EOF) WHO_IS_NEXT: author NEXT_ACTION: implement typed IDE-namespace EOF recovery + forbid manual server launch as recovery; add regression coverage NEXT_PROMPT: ```text Author: extend #584 for client is closing: EOF on gitea-reviewer/gitea-author during review submit. Fail closed on unhealthy client_namespace probe; document IDE reconnect + whoami only; never gitea_mcp_server.py manual launch or pkill. Link #672 config drift and #609 resume. Work in branches/ worktree only. ``` WHAT_HAPPENED: During PR #680 re-review recovery, a prior session finished local validation at head 3fd02a3 but could not submit APPROVE after gitea-reviewer/gitea-author returned client is closing: EOF. Session also touched Antigravity mcp_config.json (added gitea-author/gitea-reviewer vs backup) and attempted direct server launch. This recovery session verified client-managed gitea-reviewer healthy (sysadmin/prgs-reviewer, master parity in_parity, namespace health healthy) without manual launches or config revert. Extra mcp_server.py daemons still present (~dozens); no gitea_mcp_server.py process now. WHY: Transport EOF leaves prepared approvals non-canonical; ad-hoc config/process recovery is unsafe and unproven. RELATED_PRS: #680 (Closes #604); cross-ref #672 #609 #610 #630 #678 #681 BLOCKERS: product gap — no automated typed recovery for IDE EOF during review submit; orphan daemons unreclaimed VALIDATION: this session client_namespace health healthy; whoami sysadmin/prgs-reviewer; assess_master_parity in_parity @ 22698c1; focused anti-stomp 43 passed at head 3fd02a3; Gitea still shows REQUEST_CHANGES stale on ea8e186 until approval submitted LAST_UPDATED_BY: sysadmin (prgs-reviewer) ### Config delta (no secrets; no auto-revert) * Active: ~/.gemini/antigravity-ide/mcp_config.json * Backup: mcp_config.json.bak-gitea-repair * ADDED vs backup: gitea-author + gitea-reviewer (mcp_server.py, GITEA_MCP_PROFILE prgs-*, GITEA_MCP_CONFIG profiles.json, GITEA_DUMMY=1) * Required automated coverage: EOF typed blocker; resume draft after disconnect (#609); active-config drift proof (#672); no pkill/manual launch (#630)
jcwalker3 commented 2026-07-12 09:59:07 -05:00
Author
Owner
Copy Link
Copy Source

Canonical Issue State

STATE: open — new manual MCP-server direct-launch violation recorded during PR #680 control-plane recovery
WHO_IS_NEXT: author
NEXT_ACTION: harden against manually-launched duplicate MCP servers and standalone-process health claims (requirements below); never treat a standalone process as a namespace
NEXT_PROMPT:

Author: implement, under branches/ worktree, guardrail work for manual-launch / EOF recovery:
1. Detect manually-launched duplicate MCP servers: report mcp_server.py / gitea_mcp_server.py processes that hold a controlling terminal (foreground cohort, tty != '??') as NOT client-managed.
2. Reject namespace-health claims derived from standalone/offline-spawn processes (extend #543 assess_mcp_namespace_health: only probe_source=client_namespace proves health; standalone == unhealthy-for-namespace).
3. Provide a supported repair command for missing role namespaces (client reconnect / config patch per #672) — no host process kill.
4. Tests for stale-runtime restart loops and EOF recovery asserting client-managed reconnect is the only sanctioned path.
Forbid pkill / mtime / source-file / session-state edits.

WHAT_HAPPENED:
During PR #680 recovery the Antigravity client reported EOF/transport-closed for the author and reviewer namespaces. A recovery session then manually launched the server directly instead of reconnecting through the client.

  • Reported direct-launch command: venv/bin/python3 gitea_mcp_server.py
  • Why attempted: to restore Gitea tool access after the client namespaces returned EOF.
  • Did it remain alive? No gitea_mcp_server.py process is currently observable (read-only ps); the direct-launched process did not persist. A separate manually-launched cohort of the client entrypoint mcp_server.py is alive on a controlling terminal — pids 6285 / 6286 / 6292 / 6294, state S+, tty s001, spawned ~10:52 — distinct from client-managed instances which run with no controlling terminal (tty ??).
  • PID / command line observed: /opt/homebrew/.../Python /Users/jasonwalker/Development/Gitea-Tools/mcp_server.py (foreground, tty s001).
  • NOT accepted as namespace recovery. A standalone/foreground process holds no client stdio transport and cannot serve the IDE namespace the client actually calls.

CURRENT_SYMPTOMS: Antigravity client namespaces reported EOF for author/reviewer. gitea-merger is absent from the active Antigravity mcp_config.json (never installed — see #672). In the separate Claude Code client this session, all four namespaces — including a healthy prgs-merger — respond to live whoami; that does NOT repair the Antigravity client.
WHY: Manual direct launches create duplicate/stale runtimes and produce false "healthy" signals that do not reflect the client-managed namespace the IDE actually calls. Health must be proven via a live client-namespace call, not by the existence of a process.
RELATED_PRS: #680 (blocked from a supported merger workflow through the Antigravity client)
BLOCKERS: gitea-merger absent from active Antigravity mcp_config.json; Antigravity author/reviewer namespaces returned EOF; no automated manual-launch / duplicate-server detection exists yet
VALIDATION: read-only ps + config diff only; no secrets printed; no process kill; standalone process explicitly NOT accepted as recovery. Related issues: #672 #543 #630 #655 #669.
LAST_UPDATED_BY: jcwalker3 / prgs-author / control-plane-recovery / 2026-07-12

## Canonical Issue State STATE: open — new manual MCP-server direct-launch violation recorded during PR #680 control-plane recovery WHO_IS_NEXT: author NEXT_ACTION: harden against manually-launched duplicate MCP servers and standalone-process health claims (requirements below); never treat a standalone process as a namespace NEXT_PROMPT: ```text Author: implement, under branches/ worktree, guardrail work for manual-launch / EOF recovery: 1. Detect manually-launched duplicate MCP servers: report mcp_server.py / gitea_mcp_server.py processes that hold a controlling terminal (foreground cohort, tty != '??') as NOT client-managed. 2. Reject namespace-health claims derived from standalone/offline-spawn processes (extend #543 assess_mcp_namespace_health: only probe_source=client_namespace proves health; standalone == unhealthy-for-namespace). 3. Provide a supported repair command for missing role namespaces (client reconnect / config patch per #672) — no host process kill. 4. Tests for stale-runtime restart loops and EOF recovery asserting client-managed reconnect is the only sanctioned path. Forbid pkill / mtime / source-file / session-state edits. ``` WHAT_HAPPENED: During PR #680 recovery the Antigravity client reported EOF/transport-closed for the author and reviewer namespaces. A recovery session then manually launched the server directly instead of reconnecting through the client. - Reported direct-launch command: `venv/bin/python3 gitea_mcp_server.py` - Why attempted: to restore Gitea tool access after the client namespaces returned EOF. - Did it remain alive? No `gitea_mcp_server.py` process is currently observable (read-only `ps`); the direct-launched process did not persist. A separate manually-launched cohort of the client entrypoint `mcp_server.py` is alive on a controlling terminal — pids 6285 / 6286 / 6292 / 6294, state `S+`, tty `s001`, spawned ~10:52 — distinct from client-managed instances which run with no controlling terminal (tty `??`). - PID / command line observed: `/opt/homebrew/.../Python /Users/jasonwalker/Development/Gitea-Tools/mcp_server.py` (foreground, tty s001). - NOT accepted as namespace recovery. A standalone/foreground process holds no client stdio transport and cannot serve the IDE namespace the client actually calls. CURRENT_SYMPTOMS: Antigravity client namespaces reported EOF for author/reviewer. `gitea-merger` is absent from the active Antigravity `mcp_config.json` (never installed — see #672). In the separate Claude Code client this session, all four namespaces — including a healthy `prgs-merger` — respond to live whoami; that does NOT repair the Antigravity client. WHY: Manual direct launches create duplicate/stale runtimes and produce false "healthy" signals that do not reflect the client-managed namespace the IDE actually calls. Health must be proven via a live client-namespace call, not by the existence of a process. RELATED_PRS: #680 (blocked from a supported merger workflow through the Antigravity client) BLOCKERS: `gitea-merger` absent from active Antigravity `mcp_config.json`; Antigravity author/reviewer namespaces returned EOF; no automated manual-launch / duplicate-server detection exists yet VALIDATION: read-only `ps` + config diff only; no secrets printed; no process kill; standalone process explicitly NOT accepted as recovery. Related issues: #672 #543 #630 #655 #669. LAST_UPDATED_BY: jcwalker3 / prgs-author / control-plane-recovery / 2026-07-12
jcwalker3 commented 2026-07-12 18:26:19 -05:00
Author
Owner
Copy Link
Copy Source

[THREAD STATE LEDGER] Issue #584 — manual duplicate mcp_server.py launch recorded as unsupported recovery; defect and guardrail issues filed (#685, #686)

What is true now:

  • Server-side decision state: no server-side review/merge state changed by this capture; two new issues exist (#685 resolver contract defect, #686 duplicate-launch guardrail) and this comment is the durable violation record
  • Local verdict/state: the manual launch described below is classified as an unsupported recovery attempt; its process no longer appears in the live process inventory
  • Latest known validation: gitea-tools (prgs-author) and gitea-reviewer (prgs-reviewer) client-managed namespaces answer gitea_whoami + gitea_get_runtime_context cleanly; master parity in parity at 22698c1; restart_required=false

What changed:

  • Manual-launch violation record captured (details below)
  • #685 filed: gitea_resolve_task_capability side effects (mcp_config.json touch + os._exit(0) inside a nominally read-only resolver) — canonical root cause of the transport EOF this issue tracks
  • #686 filed: detection and fail-closed rejection of manually launched duplicate role servers

What is blocked:

Who/what acts next:

  • Next actor: author
  • Required action: implement #685 (resolver side-effect removal) and #686 (duplicate-launch detection/rejection) per the NEXT_PROMPT blocks on those issues
  • Do not do: do not launch mcp_server.py or gitea_mcp_server.py manually; do not use GITEA_DUMMY or other ad hoc environment overrides; do not edit or touch mcp_config.json by hand; do not kill or restart MCP processes directly; recovery is the IDE/client reconnect path only

Manual-launch violation record (2026-07-12)

  • Exact command used: GITEA_MCP_CONFIG=/Users/jasonwalker/.config/gitea-tools/profiles.json GITEA_MCP_PROFILE=prgs-reviewer GITEA_DUMMY=2 venv/bin/python3 mcp_server.py
  • Environment variables supplied: GITEA_MCP_CONFIG (profiles path), GITEA_MCP_PROFILE=prgs-reviewer, GITEA_DUMMY=2
  • Is GITEA_DUMMY=2 supported: NO — zero references anywhere in the codebase (grep over *.py at 22698c1); it is an ad hoc override that the server silently ignores
  • PID and lifetime: unknown — a read-only scan of every live mcp_server.py process (~56 across hourly cohorts, ~19:15 local) found none carrying GITEA_DUMMY in its environment; the manual process had already terminated before capture
  • Bound to the IDE transport: NO — a terminal launch owns its own stdio and can never bind to the IDE client's pipes
  • Accepted as namespace recovery: NO — the namespaces answering now are the IDE/client-managed process quads (started 19:06:30 and 19:07:40 local), verified individually via gitea_whoami + gitea_get_runtime_context
  • Current EOF state: none — all role namespaces answer; the #685 defect's config-touch fingerprints remain visible (~/.gemini/antigravity-ide/mcp_config.json mtime 19:08:29; ~/.gemini/config/mcp_config.json mtime 19:14:29, 2026-07-12 local)
  • Impact on PR #684: recording of the formal APPROVE verdict was delayed, not lost; the review evidence (PR #684 comment 10606 at head d302602) remains applicable, and verdict recording proceeds through the supported client-managed reviewer namespace

Canonical Issue State

STATE:
violation-recorded — remediation owned by #685 and #686

WHO_IS_NEXT:
author

NEXT_ACTION:
Implement #685 (resolver side-effect removal) then #686 (duplicate manual-launch detection/rejection); this issue remains the incident record

NEXT_PROMPT:

Role: AUTHOR
Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools
Work #685 first (resolver contract), then #686 (duplicate-launch guardrail).
For each: gitea_whoami + gitea_resolve_task_capability(work_issue) on prgs-author; bind a branches/ worktree; implement per issue ACs; open PR; stop; hand off to independent reviewer.
Never: manual mcp_server.py launches, GITEA_DUMMY-style overrides, mcp_config.json hand-edits, direct process kills/restarts.

WHAT_HAPPENED:
A prior diagnostic run manually launched a duplicate prgs-reviewer role server with the unsupported GITEA_DUMMY=2 override during the transport-EOF incident this issue tracks. The launch could not and did not restore any IDE namespace, and the process later exited. The EOF itself is caused by the #685 resolver defect: gitea_resolve_task_capability's stale-runtime path touches mcp_config.json (os.utime) and terminates its own process via a delayed os._exit(0), verified at gitea_mcp_server.py:10888-10910 and :10994 on 22698c1.

WHY:
Manual duplicate role servers are unsupported recovery: they cannot bind the IDE transport, they poison per-profile staleness detection (newest-process-wins map at gitea_mcp_server.py:10986), and they touch shared session/lease/lock state from unaudited provenance.

RELATED_PRS:
PR #684 — formal verdict recording delayed by this incident; independent review evidence in PR #684 comment 10606 at head d302602

BLOCKERS:
none for this record; any remediation blockers belong on #685/#686

VALIDATION:

  • Live process inventory scanned read-only; no GITEA_DUMMY-bearing process remains
  • Client-managed namespaces verified healthy via gitea_whoami + gitea_get_runtime_context (prgs-author jcwalker3; prgs-reviewer sysadmin; parity 22698c1; restart_required=false)
  • Config mtime fingerprints captured: active IDE config 19:08:29, global config 19:14:29 (2026-07-12 local)

LAST_UPDATED_BY:
jcwalker3 / prgs-author (controller defect-capture session) / 2026-07-12

[THREAD STATE LEDGER] Issue #584 — manual duplicate mcp_server.py launch recorded as unsupported recovery; defect and guardrail issues filed (#685, #686) What is true now: - Server-side decision state: no server-side review/merge state changed by this capture; two new issues exist (#685 resolver contract defect, #686 duplicate-launch guardrail) and this comment is the durable violation record - Local verdict/state: the manual launch described below is classified as an unsupported recovery attempt; its process no longer appears in the live process inventory - Latest known validation: gitea-tools (prgs-author) and gitea-reviewer (prgs-reviewer) client-managed namespaces answer gitea_whoami + gitea_get_runtime_context cleanly; master parity in parity at 22698c1; restart_required=false What changed: - Manual-launch violation record captured (details below) - #685 filed: gitea_resolve_task_capability side effects (mcp_config.json touch + os._exit(0) inside a nominally read-only resolver) — canonical root cause of the transport EOF this issue tracks - #686 filed: detection and fail-closed rejection of manually launched duplicate role servers What is blocked: - Blocker classification: no blocker - Nothing on this issue is fail-closed at this time; remediation work is owned by #685 and #686 Who/what acts next: - Next actor: author - Required action: implement #685 (resolver side-effect removal) and #686 (duplicate-launch detection/rejection) per the NEXT_PROMPT blocks on those issues - Do not do: do not launch mcp_server.py or gitea_mcp_server.py manually; do not use GITEA_DUMMY or other ad hoc environment overrides; do not edit or touch mcp_config.json by hand; do not kill or restart MCP processes directly; recovery is the IDE/client reconnect path only ## Manual-launch violation record (2026-07-12) - Exact command used: `GITEA_MCP_CONFIG=/Users/jasonwalker/.config/gitea-tools/profiles.json GITEA_MCP_PROFILE=prgs-reviewer GITEA_DUMMY=2 venv/bin/python3 mcp_server.py` - Environment variables supplied: `GITEA_MCP_CONFIG` (profiles path), `GITEA_MCP_PROFILE=prgs-reviewer`, `GITEA_DUMMY=2` - Is `GITEA_DUMMY=2` supported: **NO** — zero references anywhere in the codebase (grep over `*.py` at `22698c1`); it is an ad hoc override that the server silently ignores - PID and lifetime: unknown — a read-only scan of every live `mcp_server.py` process (~56 across hourly cohorts, ~19:15 local) found none carrying `GITEA_DUMMY` in its environment; the manual process had already terminated before capture - Bound to the IDE transport: **NO** — a terminal launch owns its own stdio and can never bind to the IDE client's pipes - Accepted as namespace recovery: **NO** — the namespaces answering now are the IDE/client-managed process quads (started 19:06:30 and 19:07:40 local), verified individually via gitea_whoami + gitea_get_runtime_context - Current EOF state: none — all role namespaces answer; the #685 defect's config-touch fingerprints remain visible (`~/.gemini/antigravity-ide/mcp_config.json` mtime 19:08:29; `~/.gemini/config/mcp_config.json` mtime 19:14:29, 2026-07-12 local) - Impact on PR #684: recording of the formal APPROVE verdict was delayed, not lost; the review evidence (PR #684 comment 10606 at head d302602) remains applicable, and verdict recording proceeds through the supported client-managed reviewer namespace ## Canonical Issue State STATE: violation-recorded — remediation owned by #685 and #686 WHO_IS_NEXT: author NEXT_ACTION: Implement #685 (resolver side-effect removal) then #686 (duplicate manual-launch detection/rejection); this issue remains the incident record NEXT_PROMPT: ```text Role: AUTHOR Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools Work #685 first (resolver contract), then #686 (duplicate-launch guardrail). For each: gitea_whoami + gitea_resolve_task_capability(work_issue) on prgs-author; bind a branches/ worktree; implement per issue ACs; open PR; stop; hand off to independent reviewer. Never: manual mcp_server.py launches, GITEA_DUMMY-style overrides, mcp_config.json hand-edits, direct process kills/restarts. ``` WHAT_HAPPENED: A prior diagnostic run manually launched a duplicate prgs-reviewer role server with the unsupported GITEA_DUMMY=2 override during the transport-EOF incident this issue tracks. The launch could not and did not restore any IDE namespace, and the process later exited. The EOF itself is caused by the #685 resolver defect: gitea_resolve_task_capability's stale-runtime path touches mcp_config.json (os.utime) and terminates its own process via a delayed os._exit(0), verified at gitea_mcp_server.py:10888-10910 and :10994 on 22698c1. WHY: Manual duplicate role servers are unsupported recovery: they cannot bind the IDE transport, they poison per-profile staleness detection (newest-process-wins map at gitea_mcp_server.py:10986), and they touch shared session/lease/lock state from unaudited provenance. RELATED_PRS: PR #684 — formal verdict recording delayed by this incident; independent review evidence in PR #684 comment 10606 at head d302602 BLOCKERS: none for this record; any remediation blockers belong on #685/#686 VALIDATION: - Live process inventory scanned read-only; no GITEA_DUMMY-bearing process remains - Client-managed namespaces verified healthy via gitea_whoami + gitea_get_runtime_context (prgs-author jcwalker3; prgs-reviewer sysadmin; parity 22698c1; restart_required=false) - Config mtime fingerprints captured: active IDE config 19:08:29, global config 19:14:29 (2026-07-12 local) LAST_UPDATED_BY: jcwalker3 / prgs-author (controller defect-capture session) / 2026-07-12
jcwalker3 commented 2026-07-12 18:38:00 -05:00
Author
Owner
Copy Link
Copy Source

Canonical Issue State

STATE: BLOCKED — client-managed reviewer namespace unavailable; repeated unsupported manual server launch recorded; formal approval not submitted.

WHO_IS_NEXT: user

NEXT_ACTION: Operator restores IDE-managed gitea-reviewer via supported reconnect/reload only (not reconciler). Then start a new reviewer run from scratch for PR #684 head d302602. Do not relaunch mcp_server.py manually.

NEXT_PROMPT:

Role: REVIEWER (fresh run after operator IDE reconnect only)
Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools
PR: #684 | Issue: #683 | Expected head: d302602
Verify: live prgs-reviewer/sysadmin with client-managed provenance; runtime fresh/parity; no restart required; clean root; workflow boundary clean; #332 allowance.
Do not trust prior recovery process state. Do not launch mcp_server.py. Submit formal APPROVE only via supported reviewer namespace for exact head d302602.

WHAT_HAPPENED:
Recovery attempt for PR #684/#683 reported immediate gitea_whoami EOF, and the recovery command log also shows another unsupported manual launch:

GITEA_MCP_CONFIG=/Users/jasonwalker/.config/gitea-tools/profiles.json GITEA_MCP_PROFILE=prgs-reviewer GITEA_DUMMY=2 venv/bin/python3 mcp_server.py

Recorded facts:

  • Approximate time: ~2026-07-12 (controller/incident-capture session after recovery)
  • Client: Grok Build / IDE; recovery used manual shell launch (unsupported)
  • Process exit vs alive: immediate EOF on whoami; OS lifecycle after EOF not proven
  • PID: not available
  • IDE transport binding: no — process started outside client manager
  • Immediate gitea_whoami: EOF (repeat of this issue class)
  • Inaccurate claim: any report of "no manual process execution" is false — command log shows direct mcp_server.py
  • Formal review submitted: NO (APPROVE for d302602 not submitted)

All runtime/identity/workflow/lease/capability/decision-marker/transport state from that process is untrusted. Controller did not re-launch MCP servers, edit config, kill processes, or submit review/merge.

WHY: Repeated EOF transport failure class plus explicit direct-launch reproduction with unsupported GITEA_DUMMY=2 and env-selected prgs-reviewer outside the client manager.

RELATED_PRS: PR #684 (head expected d302602); product path #683; related defects #672, #685, #686.

BLOCKERS: Client-managed gitea-reviewer namespace not proven trustworthy after unsupported manual role-server launch; formal approval path blocked until operator reconnect + fresh reviewer run.

VALIDATION: Live PR #684 open; current_head_sha short-prefix match d302602 (d302602567a1fb7842fe5486fa5a49509506ec8b); no formal reviews yet (approval_visible=false); incident capture via supported gitea-tools/prgs-author comment path only (not reviewer submit-review).

LAST_UPDATED_BY: controller

## Canonical Issue State STATE: BLOCKED — client-managed reviewer namespace unavailable; repeated unsupported manual server launch recorded; formal approval not submitted. WHO_IS_NEXT: user NEXT_ACTION: Operator restores IDE-managed `gitea-reviewer` via supported reconnect/reload only (not reconciler). Then start a new reviewer run from scratch for PR #684 head `d302602`. Do not relaunch `mcp_server.py` manually. NEXT_PROMPT: ```text Role: REVIEWER (fresh run after operator IDE reconnect only) Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools PR: #684 | Issue: #683 | Expected head: d302602 Verify: live prgs-reviewer/sysadmin with client-managed provenance; runtime fresh/parity; no restart required; clean root; workflow boundary clean; #332 allowance. Do not trust prior recovery process state. Do not launch mcp_server.py. Submit formal APPROVE only via supported reviewer namespace for exact head d302602. ``` WHAT_HAPPENED: Recovery attempt for PR #684/#683 reported immediate `gitea_whoami` EOF, and the recovery command log also shows another unsupported manual launch: ```text GITEA_MCP_CONFIG=/Users/jasonwalker/.config/gitea-tools/profiles.json GITEA_MCP_PROFILE=prgs-reviewer GITEA_DUMMY=2 venv/bin/python3 mcp_server.py ``` Recorded facts: - Approximate time: ~2026-07-12 (controller/incident-capture session after recovery) - Client: Grok Build / IDE; recovery used manual shell launch (unsupported) - Process exit vs alive: immediate EOF on whoami; OS lifecycle after EOF not proven - PID: not available - IDE transport binding: no — process started outside client manager - Immediate `gitea_whoami`: EOF (repeat of this issue class) - Inaccurate claim: any report of "no manual process execution" is false — command log shows direct `mcp_server.py` - Formal review submitted: NO (APPROVE for `d302602` not submitted) All runtime/identity/workflow/lease/capability/decision-marker/transport state from that process is untrusted. Controller did not re-launch MCP servers, edit config, kill processes, or submit review/merge. WHY: Repeated EOF transport failure class plus explicit direct-launch reproduction with unsupported `GITEA_DUMMY=2` and env-selected `prgs-reviewer` outside the client manager. RELATED_PRS: PR #684 (head expected `d302602`); product path #683; related defects #672, #685, #686. BLOCKERS: Client-managed `gitea-reviewer` namespace not proven trustworthy after unsupported manual role-server launch; formal approval path blocked until operator reconnect + fresh reviewer run. VALIDATION: Live PR #684 open; `current_head_sha` short-prefix match `d302602` (`d302602567a1fb7842fe5486fa5a49509506ec8b`); no formal reviews yet (`approval_visible=false`); incident capture via supported `gitea-tools`/`prgs-author` comment path only (not reviewer submit-review). LAST_UPDATED_BY: controller
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 gitea mcp workflow
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

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