Back to Signal Feed
CodeTracked since May 15, 2026

Add synchronous wait mode to `agent send` CLI

This change introduces `agent send --wait`, enabling scripts to send a prompt to an existing interactive agent session and synchronously capture the assistant’s next response from stdout. The new mode is additive: existing `agent send` behavior remains unchanged when `--wait` is omitted, which keeps backward compatibility while adding an automation-ready request/response path.

agent send--waitinteractive agent sessionstdout

What Happened

  • This change introduces `agent send --wait`, enabling scripts to send a prompt to an existing interactive agent session and synchronously capture the assistant’s next response from stdout. The new mode is additive: existing `agent send` behavior remains unchanged when `--wait` is omitted, which keeps backward compatibility while adding an automation-ready request/response path.
  • This change introduces `agent send --wait`, enabling scripts to send a prompt to an existing interactive agent session and synchronously capture the assistant’s next response from stdout. The new mode is additive: existing `agent send` behavior remains unchanged when `--wait` is omitted, which keeps backward compatibility while adding an automation-ready request/response path.
  • 1 evidence item attached for review.

What is Different

Before

Scattered source updates, isolated context, and manual follow-up across multiple feeds.

Now

The PR adds a concrete new CLI capability: a wait mode for `agent send` that returns the assistant response to stdout, turning interactive agent interaction into a blocking call pattern suitable for scripted integrations.

Why Track This

Why It Matters

Automation scripts and operators can now run deterministic send-and-receive flows against an existing interactive agent without manual polling, so integrations can progress with less glue code and fewer session-management hacks. Internally, the command adds a blocking path for `agent send` while preserving the existing non-wait fire-and-forget behavior, with an initial fixed 10-minute wait cap; after merge, teams should watch for timeout-related breakage on long-running prompts and confirm how timeout/failure states are surfaced to scripts because automation pipelines will depend on clear completion semantics.

Impact

Automation scripts and operators can now run deterministic send-and-receive flows against an existing interactive agent without manual polling, so integrations can progress with less glue code and fewer session-management hacks. Internally, the command adds a blocking path for `agent send` while preserving the existing non-wait fire-and-forget behavior, with an initial fixed 10-minute wait cap; after merge, teams should watch for timeout-related breakage on long-running prompts and confirm how timeout/failure states are surfaced to scripts because automation pipelines will depend on clear completion semantics.

What To Watch Next

  • Watch whether agent send becomes a repeated pattern.
  • Track follow-up changes around AI Workflow Automation.
  • Compare future signals against this evidence trail.
  • Re-check risk flags: hardcoded_10_minute_timeout, scripting_depends_on_stdout_stability.
Open Topic TimelineOpen Technical EventOpen Original Sourcehardcoded_10_minute_timeout / scripting_depends_on_stdout_stability / timeout_failure_signals_may_be_ambiguous / legacy_async_workflows_must_handle_wait_optional

Supporting Evidence

GITHUB PULL REQUESTHigh Trust

codeaholicguy/ai-devkit PR #83: feat(cli): add wait mode to agent send

Adds `agent send --wait` so scripts can send a prompt to an existing interactive agent session and capture the new assistant response from stdout.