Child agent end-of-task handoff strategy is hardcoded to git push + PR; should be configurable per orchestration context

[QuinceyJames]

Summary

When Warp spawns a child agent in an orchestration workflow, its end-of-task behavior is hardcoded in the system prompt to push to a remote git branch and open a draft pull request. This default conflicts with user rules prohibiting VCS operations without explicit instruction, cannot be suppressed through Settings > Agents > Profiles, and is inappropriate for local (non-ephemeral) execution environments where the filesystem persists and a git roundtrip is unnecessary.

Problem

The child agent system prompt includes a mandatory "End of task behavior" section that instructs the agent to push to a remote branch and create a draft pull request on task completion. This instruction:

1. Is hardcoded — it cannot be disabled or changed through agent profiles, permissions settings, or any currently documented mechanism.
2. Conflicts with user rules — a rule such as "do not commit or push without explicit instruction" is present in the same system prompt, but the built-in end-of-task instruction takes effective precedence for this specific VCS behaviour.
3. Does not distinguish execution context — the push/PR pattern makes sense for ephemeral remote/cloud sandboxes (where the filesystem does not persist), but is unnecessary and surprising for local agents where file changes are already present on the user's machine.
4. Produces unexpected VCS side effects — the user did not request a commit or push; the agent performed both without any explicit directive.

In the specific case that prompted this report: a child agent performing a code-writing subtask committed four new files and attempted to push to the current branch. The push was blocked by the repo's pre-push hook (pre-existing unrelated lint failures in files the agent had not touched), but the git commit was created and the push attempt was made entirely without user instruction.

Desired workflow

The orchestration platform should support configurable handoff strategies per orchestration context, with at minimum:

• message-only — child agent reports file paths and a structured summary to the orchestrator via send_message_to_agent; no VCS operations. Appropriate default for local agents.
• git-pr — push branch and open draft PR (current hardcoded behavior). Appropriate default for ephemeral remote/cloud agents.

This aligns with the industry-standard approach: OpenAI Agents SDK exposes input_filter and handoff_history_mapper to control handoff content; LangGraph, Google ADK, and Microsoft Semantic Kernel all treat handoff behavior as configurable contracts, not hardcoded side effects.

Artifacts

None attached.

Warp version

v0.2026.05.18.05.32.stable_02

Operating system

macOS 15.2 (build 24C101)

[oz-for-oss]

@QuinceyJames

Here's what I found while triaging this issue:

Thanks for the detailed report. This appears actionable as an agent orchestration handoff bug/configuration gap: local child agents should not be forced into git push/PR completion behavior when a message-only handoff is appropriate.

Maintainer details

I concluded that child-agent orchestration appears to lack a configurable handoff strategy, causing git push/PR-oriented completion behavior to be applied where a local message-only handoff is expected..

Triage summary

• Observed behavior: a child agent in an orchestration workflow reportedly created git commits and attempted to push/open a PR-style handoff even though the user did not explicitly request VCS side effects.
• Expected behavior: local child-agent handoff should be configurable, and a message-only/no-VCS handoff should be available when the orchestrator can consume local filesystem changes directly.
• Classification: this is best routed as an agent orchestration bug/configuration gap rather than a macOS-specific issue.
• Reproducibility: medium. The report includes version/OS and a concrete side effect, but no exact run transcript or minimal orchestration prompt.

Code notes

• crates/ai/src/agent/action/mod.rs defines RunAgentsRequest with summary, base_prompt, per-agent prompts, model, harness, execution mode, skills, and plan id, but no handoff-strategy field.
• crates/ai/src/agent/orchestration_config.rs similarly persists only model, harness, and execution mode for approved orchestration configs.
• app/src/ai/agent/api/convert_from.rs maps the server RunAgents tool payload into the same client request shape, again without a handoff strategy.
• app/src/ai/blocklist/action_model/execute/run_agents.rs composes the child prompt and maps run-wide config into StartAgentExecutionMode; it does not add or override any end-of-task handoff contract.
• app/src/server/server_api/ai.rs serializes AgentConfigSnapshot when creating an agent task, but the visible client task-creation path does not carry a handoff strategy.
• The exact hardcoded end-of-task instruction text appears to be generated server-/prompt-side outside this client checkout; if the desired behavior is configurable, the client/API contract likely needs an explicit field so local vs remote child runs can receive different handoff instructions.

Duplicate search

I enumerated open non-PR issues and ran focused searches for exact phrases including Child agent end-of-task, handoff strategy, message-only, draft pull request, and git push + agent, plus very recently closed issues. I did not find two or more likely duplicate issues, so this should remain a standalone report.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[kevinchevalier]

@cephalonaut Can you see if this is expected?

[cephalonaut]

We prompt the orchestrator to propose appropriate handoff procedures for remote agents but it isn't really hard coded and should be flexible in response to user directives, but we can look at being more direct in exposing options the user can set.