Skip to content

feat(agent-manager): target existing managed worktrees - #13861

Merged
marius-kilocode merged 1 commit into
mainfrom
agent-existing-worktree
Sep 7, 2026
Merged

marius-kilocode merged 1 commit into
mainfrom
agent-existing-worktree

Conversation

@marius-kilocode

Copy link
Copy Markdown
Collaborator

What Problem This Solves

Agent Manager orchestrators could create sessions only in the caller directory or in newly created worktrees. Review and follow-up sessions therefore could not target an existing managed worktree.

Why This Change Was Made

Add an explicit worktreeID start target resolved from action: "list". The target is scoped to the caller project and uses the existing local-session path.

User Impact

Fresh sessions can be started in an existing managed worktree without creating a branch, running setup, or deleting the target on failure. Existing requests without worktreeID keep their current behavior. Invalid, unknown, or foreign targets fail without fallback.

Evidence

Focused CLI and extension tests, package typechecks, extension compile, isolated VS Code self-test, and generated SDK validation passed.

Related to #13833.

@kilo-code-bot

kilo-code-bot Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (10 files)
  • .changeset/managed-worktree-target.md
  • packages/kilo-vscode/src/agent-manager/tool-start.ts
  • packages/kilo-vscode/tests/unit/agent-manager-tool-project.test.ts
  • packages/kilo-vscode/tests/unit/agent-manager-tool-start.test.ts
  • packages/opencode/src/kilocode/agent-manager/event.ts
  • packages/opencode/src/kilocode/tool/agent-manager.ts
  • packages/opencode/src/kilocode/tool/agent-manager.txt
  • packages/opencode/test/kilocode/agent-manager-tool.test.ts
  • packages/sdk/js/src/v2/gen/types.gen.ts
  • packages/sdk/openapi.json

Reviewed by grok-4.6 · Input: 97.1K · Output: 19.6K · Cached: 1.1M

Review guidance: REVIEW.md from base branch main

@WebReflection WebReflection left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think concerns around != null instead of !== aren't adding anything to this PR so I'll approve, we should probably add automatically some linter exception when that's needed or have a broader utility that allows that comparison once:

// eslint-ignore-next or something similar
const isNullish = value => value == null;

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.

2 participants