Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#63 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
53/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
bash, python
Área
cli, tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Shell
Estrellas
16
Forks
6
Merge medio
6 h 24 min
PR fusionados (30 d)
5

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de DimitriGeelen/agentic-engineering-framework

Todos los issues de DimitriGeelen/agentic-engineering-framework

Issues similares

Más issues de Shell/Bash

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.