Summary

Codex app-server command summaries can parse shell heredoc bodies as executable command stages. When an inline script or generated file contains JavaScript/YAML/shell-like text, Slack/tool-progress output can show a noisy chain such as:

run python3 inline script (heredoc) → run const slugify → run flutter-action@v2 ...

Those fragments are generated file contents, not commands that were executed.

Observed reproduction

Observed on 2026-07-02 from a Slack-started builder-courtmix session. A declined inline-script write surfaced in the ops channel as a failed command summary containing heredoc body fragments, including JavaScript const ... fragments and generated GitHub Actions YAML such as flutter-action@v2.

The operator-facing symptom is confusing because it looks like multiple commands ran and failed, when the actual command was one heredoc/inline-script launcher and the approval was declined.

Expected behavior

When an exec command contains a heredoc redirect, the display parser should summarize only the launcher command line, preserving cwd/chdir context when available. It should not split heredoc body contents into shell stages or pipeline segments.

Separately, declined command approvals should surface as declined/blocked rather than as a generic failed-command warning when that information is available.

Local workaround carried downstream

JoeArmani/openclaw-control carries a build patch named applyHeredocExecSummaryCompaction / patchExecHeredocSummaryCompaction. The patch detects heredoc redirects before summarizeExecCommand calls top-level stage splitting, then summarizes the first launcher line only.

Regression coverage: tests/build-patches/tool-display-mutations.test.mjs asserts the heredoc guard is inserted before splitTopLevelStages(cleaned).

Notes

This is distinct from issue #93139, which tracks literal \n insertion in heredoc/write contents. This issue is about the command display summary incorrectly parsing valid heredoc body text as executed command stages.