Skip to content

Add support for starting copilot with --plan or --autopilot#192

Open
kzu wants to merge 1 commit intoDamianEdwards:mainfrom
kzu:main
Open

Add support for starting copilot with --plan or --autopilot#192
kzu wants to merge 1 commit intoDamianEdwards:mainfrom
kzu:main

Conversation

@kzu
Copy link
Copy Markdown

@kzu kzu commented May 3, 2026

Fixes #191

@DamianEdwards
Copy link
Copy Markdown
Owner

DamianEdwards commented May 3, 2026

@kzu looks good other than needing an update to README.md. If you can make that change I'll go ahead and merge. Never mind, I got it.

DamianEdwards added a commit that referenced this pull request May 3, 2026
Temporary verification artifact for copilotd PR #192.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@DamianEdwards
Copy link
Copy Markdown
Owner

E2E verification found an important lifecycle concern with --plan mode.

Using an isolated COPILOTD_HOME, I verified live dispatch for the new launch options:

  • an issue rule with --autopilot launched a real copilot --remote ... --autopilot session and later re-dispatched correctly from trusted PR feedback with redispatchCount=1;
  • a PR rule with --kind pr --branch-strategy read-only --plan matched a temporary PR, created the expected detached PR worktree, and launched with --plan;
  • closing/unmatching the temporary issue/PR artifacts completed sessions and cleaned up the e2e worktrees correctly.

The concern is the issue rule using --plan: Copilot did enter plan mode (cli_plan=true) and produced plan-mode output, but it did not call back into copilotd with session complete, session comment, or session pr. From copilotd's perspective the session remained Running until the issue was later closed/unmatched, at which point reconciliation completed it.

That looks like a possible semantic mismatch rather than just a prompt miss: --plan appears optimized for producing a plan and using Copilot CLI's internal plan-mode flow, while copilotd's unattended lifecycle depends on explicit callback tool calls to advance state. Issue #162 may be the kind of future requirement/mitigation needed for --plan to work well, e.g. first-class plan lifecycle handling or a reliable way to treat produced plans as a waiting-for-review state.

Given that uncertainty, I think this PR should probably be scoped to --autopilot only for now. If prompt adjustments plus further e2e verification show that plan-mode sessions can reliably perform the required lifecycle callback, we can reconsider adding --plan support afterward.

@DamianEdwards
Copy link
Copy Markdown
Owner

Need to re-test the --plan behavior now on top of PR #199 to see if it's improved

@DamianEdwards
Copy link
Copy Markdown
Owner

E2E verification on latest main with hook coordination

I re-ran verification of this PR rebased on latest main after Prototype Copilot hook coordination landed.

Environment verified

  • Rebased PR commit 2d0b2f0 onto origin/main 7592dc1, producing local verification commit 99c875e.
  • Built successfully with dotnet build .\src\copilotd\copilotd.csproj -nologo.
  • Published a standalone copilotd.exe outside the source tree and used an isolated COPILOTD_HOME.
  • Created a scoped temporary issue rule for DamianEdwards/copilotd with --plan and label copilotd-e2e-pr192-plan.
  • Control sessions were disabled; temporary GitHub issues/labels/branches/worktrees were cleaned up afterward.

Result: not yet suitable to include on the assumption that hooks make --plan lifecycle-safe.

Two live issues were dispatched through copilotd:

  1. #204 included an explicit extra prompt instruction telling the agent to run the copilotd lifecycle callback when done. It launched with --plan, installed .github/hooks/copilotd.hooks.json, and reached CompletedBySession=true. However, LastHookEvent stayed null, so this only proved that an explicit session complete instruction works; it did not prove hook enforcement.
  2. #205 removed the explicit lifecycle instruction and asked only for a concise plan. It launched with --plan, installed hook config pointing at the published copilotd.exe, and generated a plan artifact under Copilot's session state. It then remained Running with LastHookEvent=null, no remote URL, and no agentStop/sessionEnd hook evidence in the Copilot process log.

The observed behavior suggests plan mode creates/holds a plan and waits for approval rather than attempting to end the agent turn, so the agentStop hook does not fire and cannot force a lifecycle transition. That means --plan dispatched sessions can still remain active/idle instead of converging to Completed, WaitingForFeedback, or WaitingForReview.

Static review did not find issues in the flag plumbing itself, but there are related behavioral risks still worth resolving or explicitly deciding:

  • --autopilot and --plan can both be configured on the same rule, with no validation.
  • Resume behavior for plan-mode sessions is unclear.
  • Permission semantics for --autopilot vs. --yolo/--allow-all-tools are not documented or validated.

Cleanup completed: temporary issues #204 and #205 were closed, the temporary label was deleted, remote branches copilotd/issue-204-87dc and copilotd/issue-205-2324 were deleted, local verification worktrees were removed, and the repo was returned to clean main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add support for starting copilot with --plan or --autopilot

3 participants