Summary
agent-terminal run currently uses a visible in-terminal completion sentinel like __AT_MARKER_<id>__ when it is waiting for command completion.
That behavior is acceptable for now, but it leaks an internal implementation detail into screenshots, WebM exports, asciicasts, and other reviewer-facing proof artifacts.
Current behavior
Today, the run wait path appends a printable marker after the injected command and waits until the renderer sees that marker in visible terminal output.
This provides a strong correctness/ordering guarantee:
- the PTY received the command,
- the shell reached the end of the injected command,
- the sentinel was emitted,
- and the renderer replay caught up far enough to observe it.
That is why the current approach is in-band instead of purely out-of-band.
Problem
Even though the current behavior is correct, the visible marker can make proof artifacts noisy and confusing. In practice, reviewers can end up seeing __AT_MARKER_*__ strings in screenshots or recordings and wonder whether they are part of the app under test.
Desired improvement
Preserve the semantics of run --wait, but replace the visible sentinel with a completion signal that does not show up in rendered terminal output.
Constraints
Any future change should preserve the existing guarantees:
run --wait should still mean actual command completion, not merely input injection.
- The solution should remain compatible with the event-log-as-truth architecture.
- Replay, screenshots, and exports should remain deterministic.
- The behavior should stay robust across supported shells and common interactive workflows.
Possible directions
-
Hidden / non-rendered sentinel
- Keep a shell-emitted completion token, but make it non-rendered and detect it without painting it into the terminal surface.
-
True out-of-band completion signal
- Wrap command execution so completion is reported back to the host on a side channel, then recorded in the event log without writing visible terminal text.
-
Shell-aware completion integration
- Use a shell-specific wrapper or prompt-aware mechanism instead of a printed sentinel.
- This may provide a cleaner UX, but likely at the cost of portability and complexity.
Acceptance criteria
- Internal
run completion signaling no longer appears in normal screenshots, snapshots, WebM exports, or asciicasts.
run --wait still waits for true command completion.
- The resulting mechanism is covered by integration/e2e tests.
- Dogfood proof should verify that reviewer-facing artifacts stay clean.
Notes
This is a future improvement request, not a release blocker. The current implementation is acceptable; this issue is meant to capture the cleanup opportunity.
Generated with mux • Model: openai:gpt-5.4 • Thinking: xhigh
Summary
agent-terminal runcurrently uses a visible in-terminal completion sentinel like__AT_MARKER_<id>__when it is waiting for command completion.That behavior is acceptable for now, but it leaks an internal implementation detail into screenshots, WebM exports, asciicasts, and other reviewer-facing proof artifacts.
Current behavior
Today, the
runwait path appends a printable marker after the injected command and waits until the renderer sees that marker in visible terminal output.This provides a strong correctness/ordering guarantee:
That is why the current approach is in-band instead of purely out-of-band.
Problem
Even though the current behavior is correct, the visible marker can make proof artifacts noisy and confusing. In practice, reviewers can end up seeing
__AT_MARKER_*__strings in screenshots or recordings and wonder whether they are part of the app under test.Desired improvement
Preserve the semantics of
run --wait, but replace the visible sentinel with a completion signal that does not show up in rendered terminal output.Constraints
Any future change should preserve the existing guarantees:
run --waitshould still mean actual command completion, not merely input injection.Possible directions
Hidden / non-rendered sentinel
True out-of-band completion signal
Shell-aware completion integration
Acceptance criteria
runcompletion signaling no longer appears in normal screenshots, snapshots, WebM exports, or asciicasts.run --waitstill waits for true command completion.Notes
This is a future improvement request, not a release blocker. The current implementation is acceptable; this issue is meant to capture the cleanup opportunity.
Generated with
mux• Model:openai:gpt-5.4• Thinking:xhigh