Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Bug: orchestrator-mcp-scan.sh dies with E2BIG (exit 126) once termlink list --json exceeds MAX_ARG_STRLEN

Aperta
  • Qualcosa non va?
#63 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
53/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
bash, python
Ambito
cli, tooling

Direzione di ricerca

Start by reading agents/audit/orchestrator-mcp-scan.sh, especially the SESSIONS_JSON export and Python heredoc, then run the script with a session list larger than MAX_ARG_STRLEN. The issue includes an example fix that passes the bulk data through a temporary file; verify the scan no longer exits 126 and can report its backlog. The report also mentions a separate non-interactive prompt in lib/upstream.sh:299, which is outside the main bug.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Context

  • Framework version: 1.6.258
  • Project: 050-email-archive (shared-tooling mode)
  • Reported: 2026-09-25T00:02:17Z

Description

Summary

agents/audit/orchestrator-mcp-scan.sh passes the full output of termlink list --json to
Python through an exported environment variable (SESSIONS_JSON). Linux caps each
individual argv/envp string at MAX_ARG_STRLEN = 32 x PAGE_SIZE = 131,072 bytes,
independently of the much larger total-size limit. Once a fleet's session list crosses that
cap, the execve of python3 fails with E2BIG and the script exits 126 before a single
line of Python runs.

The orchestrator-arc MCP scan is the drift defense for MCP-tool task_id enforcement (T-1646)
— it is the check that notices when a gated MCP tool loses its check_task_governance. When
this fires, that check is not degraded, it is dead.

Why it matters more than a normal probe failure

  1. It is monotonic, not intermittent. The payload grows with fleet size. Once over the cap
    it can never recover on its own, and it gets worse with every session added.
  2. Its death is invisible. The parallel framework-mcp leg on the same scan still reports
    [PASS] in the same audit section, so the section reads healthy.
  3. audit.sh mislabels the cause. The probe-failure branch (audit.sh:~4623) emits a
    hardcoded evidence string — "Cannot reach /opt/termlink via direct read or termlink interact" — for any non-0/1/2 exit. Only $ORCH_EXIT_CAPTURED is measured. On our host
    /opt/termlink is reachable and termlink list --json works, so the stated cause is false
    and the suggested mitigation ("check FW_TERMLINK_REPO and TermLink session availability")
    sends the reader to two healthy subsystems. Filed separately on our side; flagged here
    because the two together are why this sat unfixed.

Measured (framework v1.6.258, 2026-09-25)

$ bash agents/audit/orchestrator-mcp-scan.sh
agents/audit/orchestrator-mcp-scan.sh: line 141: /usr/bin/python3: Argument list too long
EXIT=126

$ termlink list --json | wc -c
186907            # 1.43x over the 131072-byte cap

After the fix, same host

Exit 126 -> exit 1, and the scan reported a real backlog on its first successful run:
tools 260 vs baseline 263; 6 new unclassified tools (termlink_fleet_governor_history,
termlink_fleet_governor_status, termlink_hub_governor_status,
termlink_substrate_history, termlink_substrate_status, termlink_whoami); 12 removed;
TAG-FORMAT-DRIFT on 4 non-canonical prefixes; 347 sessions tag-linted. Restoring this detector
makes the audit louder, which is the point.

Patch (applied to our vendored copy; diff inline, deliberately NOT --attach-patch)

Bulk payload travels by file; only the short path is exported. Note python3 - <<'PYEOF'
already consumes stdin for the script itself, so a temp file is the fix rather than a naive
stdin swap. A guard over the remaining exported values fails loudly naming E2BIG /
MAX_ARG_STRLEN instead of surfacing an opaque 126.

-SESSIONS_JSON=$(probe_sessions_json)
+SESSIONS_JSON_FILE=$(mktemp -t orch-sessions-XXXXXX.json)
+trap 'rm -f "$SESSIONS_JSON_FILE"' EXIT
+probe_sessions_json > "$SESSIONS_JSON_FILE"

-export CURRENT_TOOLS CURRENT_GATED BASELINE LATEST SESSIONS_JSON APPLY_MODE \
+export CURRENT_TOOLS CURRENT_GATED BASELINE LATEST SESSIONS_JSON_FILE APPLY_MODE \
        CURRENT_FRAMEWORK_TOOLS CURRENT_FRAMEWORK_GATED FRAMEWORK_BASELINE
+
+ORCH_MAX_ARG_STRLEN=131072
+for _v in CURRENT_TOOLS CURRENT_GATED BASELINE LATEST SESSIONS_JSON_FILE APPLY_MODE \
+          CURRENT_FRAMEWORK_TOOLS CURRENT_FRAMEWORK_GATED FRAMEWORK_BASELINE; do
+  eval "_len=\${#$_v}"
+  if [ "$_len" -ge "$ORCH_MAX_ARG_STRLEN" ]; then
+    echo "ERROR: \$$_v is $_len bytes, at or over MAX_ARG_STRLEN ($ORCH_MAX_ARG_STRLEN)." >&2
+    echo "       execve would fail with E2BIG (shell reports exit 126). Pass this value" >&2
+    echo "       by file like SESSIONS_JSON_FILE instead of exporting it." >&2
+    exit 2
+  fi
+done
 python3 - <<'PYEOF'

-sessions_json = os.environ.get('SESSIONS_JSON', '') or ''
+_sessions_path = os.environ.get('SESSIONS_JSON_FILE', '')
+try:
+    with open(_sessions_path) as _fh:
+        sessions_json = _fh.read()
+except (OSError, ValueError):
+    sessions_json = ''

Suggested generalisation

Any probe output of unbounded size should travel by file or stdin, never export. The guard
above is the cheap version; a shared helper would be better, since CURRENT_TOOLS is on the
same trajectory as the MCP tool inventory grows.

Second, smaller report while here: fw upstream report cannot be driven non-interactively

lib/upstream.sh:299 calls a bare read -r confirm. With no TTY (CI, claude -p, any
scripted caller) the verb hangs indefinitely rather than failing. The only escape is
--force, which also skips the duplicate check — the flag conflates "I am not interactive"
with "do not check for duplicates", so a non-interactive caller is pushed toward disabling a
safety check it has no reason to disable. Suggest either honouring a piped y (works today),
detecting [ ! -t 0 ] and erroring with guidance, or splitting --force into
--yes / --skip-duplicate-check.

Reported from consumer project Pen (050-email-archive), task T-2189, arc-009.

Reported via fw upstream report from field installation

Lingua principale
Shell
Stelle
16
Fork
6
Merge medio
6h 24m
PR unite (30g)
5

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DimitriGeelen/agentic-engineering-framework

Tutte le issue di DimitriGeelen/agentic-engineering-framework

Issue simili

Altre issue su Shell/Bash

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.