gitea_resolve_task_capability is not side-effect free: stale-runtime path touches mcp_config.json and terminates its own process (os._exit) causing client EOF #685

New Issue

2026-07-12T18:23:59-05:00

jcwalker3 commented

2026-07-12 18:23:59 -05:00

Problem

gitea_resolve_task_capability is documented and treated as read-only, but its stale-runtime path mutates external MCP client configuration and destroys the active client transport. A nominally read-only preflight resolver must never do either.

Canonical root cause (verified at master `22698c1`)

gitea_resolve_task_capability calls _check_mcp_runtimes_diagnostics (gitea_mcp_server.py:11218; also invoked from :757 and :4645; function at :10913).
When the serving process is classified stale (start_time < code_mtime of gitea_mcp_server.py, or boot HEAD != current HEAD), it invokes _trigger_mcp_auto_restart() (:10993–10994).
_trigger_mcp_auto_restart (:10888) touches the MCP client config — os.utime(config_path, None) at :10901, default ~/.gemini/config/mcp_config.json, MCP_CONFIG_PATH override — changing its modification time to provoke a client reload.
It then spawns a daemon thread that sleeps 1.0 s and calls os._exit(0) (:10905–10910), terminating the serving process from inside a tool call.
The client transport closes with EOF; every namespace bound to that process drops mid-session.
Net effect: a read-only capability resolver mutates external configuration and destroys the active transport.

Additional side effects present on every resolver call, even with a fresh runtime: _check_mcp_runtimes_diagnostics spawns subprocesses — ps -ax (:10927), a per-PID ps eww for every mcp_server.py process found (:10968), and git rev-parse HEAD (:10936).

Related poisoning defect: the staleness scan keeps only the newest process per profile (running_profiles, :10986), so a manually launched duplicate role server masks stale client-managed runtimes. Guardrail work for detecting/rejecting such duplicates is tracked separately (see linkage below).

Observed incident (2026-07-12, #584 / #672 cluster)

During PR #684 formal-verdict recovery, a resolver call on a stale runtime triggered the auto-restart path.
Config touch fingerprints: ~/.gemini/antigravity-ide/mcp_config.json mtime 19:08:29, ~/.gemini/config/mcp_config.json mtime 19:14:29 (local, 2026-07-12).
Client transport returned EOF; the session lost all role namespaces at once (matches the #584 signature).
The EOF then provoked an unsupported manual recovery attempt (GITEA_DUMMY=2 venv/bin/python3 mcp_server.py — see violation record on #584/#672), compounding the damage surface.
Formal APPROVE recording for PR #684 (evidence comment 10606, head d302602) was delayed until a supported client-managed reviewer namespace was available.

Acceptance criteria

Capability resolution is side-effect free.
No config file is touched or edited.
No process is spawned, killed, signaled, or terminated.
No thread is created for recovery.
No client or daemon reload is triggered.
Stale runtime returns a typed blocker: blocker_kind=runtime_reconnect_required, stop_required=true, restart_required=true, mutation_performed=false, and a precise exact_next_action.
Recovery is owned by the IDE/client reconnect path — never by the resolver.
A fresh process must repeat all preflight and cannot inherit capability, workflow, lease, or decision state.
Tests verify unchanged: config contents, config mtime, process inventory, thread inventory, session state, lease state.
Tests cover author, reviewer, merger, and reconciler profiles.
Repeated resolver calls cannot cause an EOF/restart loop.
Tool metadata and documentation accurately state whether the resolver is read-only.

Required tests

Resolver call on a stale runtime: assert typed blocker returned; assert config mtime/contents, process table, thread count, session/lease state all unchanged; assert the process is still alive afterward.
Resolver call repeated N times on a stale runtime: no exit, no reload, no EOF loop.
All four role profiles (author, reviewer, merger, reconciler) exercise the same contract.
Regression: _trigger_mcp_auto_restart (or successor) is unreachable from any read-only tool.

Explicit non-goals

Do not weaken stale-runtime detection — fail-closed reporting stays; only the self-recovery side effects are removed.
Do not add any new restart path; governed restart work belongs to #655/#657/#669.

Linkage

Incident cluster: #584 (transport EOF), #672 (Antigravity config drift; explicitly lists gitea_mcp_server.py auto-restart/config-touch as a non-repair path).
Related, not owners: #610 (resolver vs parity staleness disagreement), #630 (manual process-kill contamination), #655/#657 (restart governance/inventory — #657 will inventory _trigger_mcp_auto_restart; this issue removes it from the resolver), #669 (scoped recovery), #678 (sanctioned reconnect exposure).

Canonical issue state

STATE: ready-for-author
WHO_IS_NEXT: author
NEXT_ACTION: Make gitea_resolve_task_capability side-effect free; stale runtime returns typed runtime_reconnect_required blocker; delete config-touch/os._exit recovery from the resolver path
NEXT_PROMPT:
Role: AUTHOR
Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools
Issue: this issue

1. gitea_whoami + gitea_resolve_task_capability(work_issue) on prgs-author; bind an issue-backed worktree under branches/ (never the root checkout).
2. Remove _trigger_mcp_auto_restart invocation from _check_mcp_runtimes_diagnostics and any other read-only path; keep stale detection.
3. Stale runtime → return typed blocker: blocker_kind=runtime_reconnect_required, stop_required=true, restart_required=true, mutation_performed=false, precise exact_next_action pointing at IDE/client reconnect.
4. Eliminate config os.utime, thread spawn, and os._exit from the resolver path entirely; recovery is owned by the IDE/client.
5. Minimize/eliminate subprocess use in the resolver hot path or document why any read-only subprocess is required.
6. Tests per issue AC 9–11 across all four role profiles; verify config contents+mtime, process/thread inventory, session/lease state unchanged; repeated-call loop test.
7. Update tool docstring/docs to state the true read-only contract.
8. PR with Closes reference to this issue; stop; hand off to independent reviewer.

Required final evidence

PR removing the side effects, typed-blocker output sample, and the unchanged-environment test battery across all four profiles.

## Problem `gitea_resolve_task_capability` is documented and treated as **read-only**, but its stale-runtime path mutates external MCP client configuration and destroys the active client transport. A nominally read-only preflight resolver must never do either. ## Canonical root cause (verified at master `22698c1`) 1. `gitea_resolve_task_capability` calls `_check_mcp_runtimes_diagnostics` (`gitea_mcp_server.py:11218`; also invoked from `:757` and `:4645`; function at `:10913`). 2. When the serving process is classified stale (`start_time < code_mtime` of `gitea_mcp_server.py`, or boot HEAD != current HEAD), it invokes `_trigger_mcp_auto_restart()` (`:10993–10994`). 3. `_trigger_mcp_auto_restart` (`:10888`) touches the MCP client config — `os.utime(config_path, None)` at `:10901`, default `~/.gemini/config/mcp_config.json`, `MCP_CONFIG_PATH` override — changing its modification time to provoke a client reload. 4. It then spawns a daemon thread that sleeps 1.0 s and calls `os._exit(0)` (`:10905–10910`), terminating the serving process from inside a tool call. 5. The client transport closes with EOF; every namespace bound to that process drops mid-session. 6. Net effect: a read-only capability resolver mutates external configuration and destroys the active transport. Additional side effects present on **every** resolver call, even with a fresh runtime: `_check_mcp_runtimes_diagnostics` spawns subprocesses — `ps -ax` (`:10927`), a per-PID `ps eww` for every `mcp_server.py` process found (`:10968`), and `git rev-parse HEAD` (`:10936`). Related poisoning defect: the staleness scan keeps only the newest process per profile (`running_profiles`, `:10986`), so a manually launched duplicate role server masks stale client-managed runtimes. Guardrail work for detecting/rejecting such duplicates is tracked separately (see linkage below). ## Observed incident (2026-07-12, #584 / #672 cluster) * During PR #684 formal-verdict recovery, a resolver call on a stale runtime triggered the auto-restart path. * Config touch fingerprints: `~/.gemini/antigravity-ide/mcp_config.json` mtime 19:08:29, `~/.gemini/config/mcp_config.json` mtime 19:14:29 (local, 2026-07-12). * Client transport returned EOF; the session lost all role namespaces at once (matches the #584 signature). * The EOF then provoked an **unsupported manual recovery attempt** (`GITEA_DUMMY=2 venv/bin/python3 mcp_server.py` — see violation record on #584/#672), compounding the damage surface. * Formal APPROVE recording for PR #684 (evidence comment 10606, head d302602) was delayed until a supported client-managed reviewer namespace was available. ## Acceptance criteria 1. Capability resolution is side-effect free. 2. No config file is touched or edited. 3. No process is spawned, killed, signaled, or terminated. 4. No thread is created for recovery. 5. No client or daemon reload is triggered. 6. Stale runtime returns a typed blocker: `blocker_kind=runtime_reconnect_required`, `stop_required=true`, `restart_required=true`, `mutation_performed=false`, and a precise `exact_next_action`. 7. Recovery is owned by the IDE/client reconnect path — never by the resolver. 8. A fresh process must repeat all preflight and cannot inherit capability, workflow, lease, or decision state. 9. Tests verify unchanged: config contents, config mtime, process inventory, thread inventory, session state, lease state. 10. Tests cover author, reviewer, merger, and reconciler profiles. 11. Repeated resolver calls cannot cause an EOF/restart loop. 12. Tool metadata and documentation accurately state whether the resolver is read-only. ## Required tests * Resolver call on a stale runtime: assert typed blocker returned; assert config mtime/contents, process table, thread count, session/lease state all unchanged; assert the process is still alive afterward. * Resolver call repeated N times on a stale runtime: no exit, no reload, no EOF loop. * All four role profiles (author, reviewer, merger, reconciler) exercise the same contract. * Regression: `_trigger_mcp_auto_restart` (or successor) is unreachable from any read-only tool. ## Explicit non-goals * Do not weaken stale-runtime **detection** — fail-closed reporting stays; only the self-recovery side effects are removed. * Do not add any new restart path; governed restart work belongs to #655/#657/#669. ## Linkage * Incident cluster: #584 (transport EOF), #672 (Antigravity config drift; explicitly lists `gitea_mcp_server.py` auto-restart/config-touch as a non-repair path). * Related, not owners: #610 (resolver vs parity staleness disagreement), #630 (manual process-kill contamination), #655/#657 (restart governance/inventory — #657 will inventory `_trigger_mcp_auto_restart`; this issue removes it from the resolver), #669 (scoped recovery), #678 (sanctioned reconnect exposure). ## Canonical issue state ```text STATE: ready-for-author WHO_IS_NEXT: author NEXT_ACTION: Make gitea_resolve_task_capability side-effect free; stale runtime returns typed runtime_reconnect_required blocker; delete config-touch/os._exit recovery from the resolver path NEXT_PROMPT: Role: AUTHOR Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools Issue: this issue 1. gitea_whoami + gitea_resolve_task_capability(work_issue) on prgs-author; bind an issue-backed worktree under branches/ (never the root checkout). 2. Remove _trigger_mcp_auto_restart invocation from _check_mcp_runtimes_diagnostics and any other read-only path; keep stale detection. 3. Stale runtime → return typed blocker: blocker_kind=runtime_reconnect_required, stop_required=true, restart_required=true, mutation_performed=false, precise exact_next_action pointing at IDE/client reconnect. 4. Eliminate config os.utime, thread spawn, and os._exit from the resolver path entirely; recovery is owned by the IDE/client. 5. Minimize/eliminate subprocess use in the resolver hot path or document why any read-only subprocess is required. 6. Tests per issue AC 9–11 across all four role profiles; verify config contents+mtime, process/thread inventory, session/lease state unchanged; repeated-call loop test. 7. Update tool docstring/docs to state the true read-only contract. 8. PR with Closes reference to this issue; stop; hand off to independent reviewer. ``` ## Required final evidence PR removing the side effects, typed-blocker output sample, and the unchanged-environment test battery across all four profiles.

jcwalker3 added the status:ready workflow-hardening anti-stomp mcp-health stale-runtime type:bug labels 2026-07-12 18:23:59 -05:00

gitea_resolve_task_capability is not side-effect free: stale-runtime path touches mcp_config.json and terminates its own process (os._exit) causing client EOF #685