feat(agent-manager): open notification Show in Agent Manager for its sessions

[sylwester-liljegren]

Issue

Fixes #13922

Context

Attention notifications (added in #13771) always opened their Show action through the sidebar. When the notification came from an Agent Manager session, that pulled the session out of the panel the user is actually working in and into the sidebar. The sidebar is only the right destination for sessions Agent Manager does not own.

Implementation

AttentionService's show callback now asks Agent Manager first. AgentManagerProvider.revealSession() returns false when Agent Manager does not own the session, and the existing sidebar path runs unchanged.

Ownership is resolved host-side from getSessionDirectories(). The session's directory is matched back to its owning project context and worktree, and the reveal is refused unless the worktree still exists and still matches that directory. That makes the stale cases (worktree removed, session moved back to Local, directory no longer owned) fall back to the sidebar instead of selecting the wrong thing.

Ordering matters in the host: the project is activated and the project catalog is published before the reveal message is posted. The webview rejects messages for a project other than its applied one, so without the catalog push the reveal could be dropped when the notification came from a non-active project.

The webview side reuses focusManagedSession, which already selects the worktree, clears review/terminal state, and selects the session tab. It gained a scrollToBottom flag so the reveal path passes selectSession(id, { scrollToBottom: true }) — the same one-shot request MessageList consumes for the sidebar in #13771, so a later switch back still restores the saved scroll position.

Two notes for reviewers:

• Reveal orchestration lives in reveal-session.ts rather than the provider because AgentManagerProvider.ts is at its enforced maxLines cap.
• For the same reason, the path-resolution body of openWorktreeFile moved unchanged into worktree-file-path.ts. This is the only refactor in the PR and is behavior-preserving; it is covered by new tests, since that symlink-traversal logic previously had none.

Screenshots / Video

agent_manager_navigation_with_notifications.1.mp4

How to Test

Manual/local verification

• Ran bun run extension:isolated and confirmed a worktree agent that asks a question raises a notification whose Show focuses Agent Manager, selects that worktree and session tab, and scrolls to the latest message
• Confirmed a sidebar (non-Agent-Manager) session still opens in the sidebar
• Confirmed deleting the worktree before clicking Show falls back to the sidebar instead of failing

Reviewer test steps

1. Open Agent Manager and start a worktree agent
2. Prompt it so it needs attention, e.g. "Ask me to choose between two implementation approaches"
3. Click Show on the notification
4. Confirm Agent Manager is focused with the correct project, worktree, and session tab selected, scrolled to the latest message
5. Repeat with a normal sidebar session and confirm Show still opens the sidebar
6. Delete an Agent Manager worktree that has a pending notification, click Show, and confirm it falls back to the sidebar

Blocked checks and substitute verification

• bun run test:unit (full extension suite) could not complete in the available time budget; substitute verification was the targeted suites agent-manager-reveal-session, worktree-file-path, agent-manager-arch, attention, agent-manager-focus, agent-manager-focus-panel, agent-manager-provider-lifecycle, agent-manager-session-restore, agent-manager-selection-actions, project-message-ownership, project-local-navigation, session-scroll-bottom, and presence-registration-contract, all passing
• bun run check-kilocode-change cannot run in this Windows PowerShell environment (the script is shell-specific); verified instead by searching the package for kilocode_change, which returns no matches — and markers are not required in packages/kilo-vscode/
• src/agent-manager/__tests__/AgentManagerProvider.spec.ts fails (1 pass / 10 fail), but it fails identically on a clean checkout of main; verified by stashing this branch's changes and re-running, so it is pre-existing and unrelated

All checks above were executed by the agent. bun run typecheck, bun run lint, bun run knip, and bun run format pass.

Checklist

• Issue linked above, or exception explained
• Tests/verification described
• Screenshots/video included for visual changes, or marked N/A
• Changeset considered for user-facing changes
• I personally reviewed the diff and can explain the changes, including any AI-assisted work.

Get in Touch

sylwester-liljegren

[kilo-code-bot]

Code Review Summary

Status: 2 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	1

Issue Details (click to expand)

WARNING

File	Line	Issue
packages/kilo-vscode/src/agent-manager/reveal-session.ts	65	Always re-activates the current project on Show, resetting PR/stats/busy state

SUGGESTION

File	Line	Issue
packages/kilo-vscode/src/agent-manager/reveal-session.ts	33	Local Agent Manager sessions still fall back to the sidebar

Files Reviewed (9 files)

• .changeset/agent-manager-notification-navigation.md
• packages/kilo-vscode/src/agent-manager/AgentManagerProvider.ts
• packages/kilo-vscode/src/agent-manager/reveal-session.ts - 2 issues
• packages/kilo-vscode/src/agent-manager/worktree-file-path.ts
• packages/kilo-vscode/src/extension.ts
• packages/kilo-vscode/tests/unit/agent-manager-reveal-session.test.ts
• packages/kilo-vscode/tests/unit/worktree-file-path.test.ts
• packages/kilo-vscode/webview-ui/agent-manager/AgentManagerApp.tsx
• packages/kilo-vscode/webview-ui/src/types/messages/extension-messages.ts

Fix these issues in Kilo Cloud

---

_{Reviewed by grok-4.6 · Input: 208.1K · Output: 34.1K · Cached: 2.6M}

_{Review guidance: REVIEW.md from base branch main}

[sylwester-liljegren]

Both findings were valid — addressed in 74740a4.

WARNING — always re-activates the current project (reveal-session.ts:65)

Correct, and this was the more serious of the two. activateProject() stops the stats poller, resets the PR bridge, clears busySessions, and drops the cached worktree/local stats. Because the reveal called it unconditionally, the most common case — clicking Show for a session in the project already on screen — needlessly reset live state and forced a refetch.

Activation (and the catalog push) now runs only when the target project differs from the active one:

if (contexts.active()?.id !== target.projectId) {
  contexts.activate(target.projectId)
  deps.activate(target.context)
  deps.projects()
}

Covered by a new test asserting nothing is activated and only open/state run when the project is already active.

SUGGESTION — Local Agent Manager sessions fall back to the sidebar (reveal-session.ts:33)

Agreed that these are owned by Agent Manager, so they now reveal there. The reveal message's worktreeId is optional, and the webview routes a worktree-less reveal through the existing focusLocalSession, which gained the same one-shot scrollToBottom flag.

One caveat worth calling out, because it makes the naive version of this fix unsafe: collectProjectSessions registers every live root session into the panel's session→directory map, including ordinary sidebar sessions in the same repository. Treating "directory === project root" as ownership would therefore have hijacked plain sidebar sessions — the exact regression the issue warns against. Local ownership consequently requires a session persisted in agent-manager.json (state.getSession(id) with a null worktreeId), which is true for Agent Manager Local tabs and false for sidebar sessions. There is a test for each direction.

The worktree path is unchanged and still accepts live-but-unpersisted sessions, since a session in a worktree directory belongs to Agent Manager either way.

Verification: typecheck, lint, knip, format, plus the reveal, arch, attention, focus, selection-action, local-navigation, and scroll suites all pass.

[sylwester-liljegren]

@marius-kilocode Here you have the PR specifically for the agent manager navigation using VS Code notifications. Maybe it should have been part of that larger PR after all, didn't seem to be too complicated to get it right. But I am not a frequent user of the Agent Manager UI, so I leave it up to you to decide whether this is good or not.

[marius-kilocode]

Very cool, I will give it a spin soon @sylwester-liljegren

[marius-kilocode]

The change looks correct, I wrote down some thoughts on how we would be able to iterate further on native notification actions: #14010

Thanks

[sylwester-liljegren]

Glad that you liked it, @marius-kilocode !