Q: Why does the autonomous agent stop mid-task after posting a progress update text?

This is a known bug (v0.13.6): the agent-runtime `runLoop` treats any assistant message with zero tool calls as the final answer and emits `agent_end`. When the model follows the system prompt's instruction to write a short progress sentence before the next tool batch—but streams that text with `finish_reason: "stop"` and no bundled `tool_call`—the loop sees `toolCalls.length === 0` and halts the run prematurely. Workaround: manually send a follow-up prompt (e.g., "continue") to resume the task. Proper fixes (choose one): 1) Patch `runLoop` so that in autonomous mode, an assistant message containing text but no tool calls and no explicit task-completion marker triggers one auto-continue/nudge (similar to the existing `pendingSilentTurnRerun`/`SILENT_TURN_NUDGE` recovery in sidecar.js) instead of terminating. 2) Amend the collaboration system prompt to require: "Always emit the tool call in the same message as your text update; never announce an action without the corresponding tool call in the same turn, or execution will terminate."

Question 1

Why is my position: fixed submenu misaligned when the parent menu uses backdrop-filter (blur)?

Accepted Answer

Root cause: an element with `backdrop-filter` (non-`none`) becomes the containing block for all its `position: fixed` descendants, so the submenu is positioned relative to the menu instead of the viewport — causing offset flyouts, horizontal scrollbars, and overflow blank areas. Fix: render the submenu through a React Portal to `document.body` so it escapes the menu's box tree and `fixed` anchors back to the viewport: ```tsx {openSubmenuItem ? createPortal(

, document.body, ) : null} ``` Two follow-up adjustments since the submenu is no longer a DOM child of the root menu: (1) in the root menu's `onPointerLeave`, treat `relatedTarget` inside the portaled submenu as still inside the menu, otherwise the submenu closes when the mouse moves into it; (2) add `onPointerLeave` on the submenu panel itself to close it when the pointer leaves both. Keyboard navigation needs no change — React events bubble through the React tree, so the root menu's `onKeyDown` and `closest('[role="menu"]')` still work. Also reposition the submenu on root menu resize/scroll so it tracks the trigger row. Note the same breakage occurs with ancestor `transform` or `zoom`, and the Portal fix covers all of them.

Question 2

How to fix 'EPERM: operation not permitted, symlink' and path assertion test failures when running vitest on a Windows dev checkout?

Accepted Answer

These were test-fixture bugs (not product bugs), fixed by PR #1803 and merged to main as commit d1df8bba0. Pull the latest main (after 0.21.0-beta.4) and rerun: `cd packages/host-runtime && pnpm exec vitest run src/launch-resolver.test.ts` and `cd packages/agent-runtime && pnpm exec vitest run src/native-pi-session.test.ts -t sessionDir`. The fixes: (1) the launch-resolver test no longer hardcodes the POSIX path `/data/scratch/s1` — it builds the expected path with the host platform's `join()`, matching Windows `\data\scratch\s1`; (2) the sessionDir symlink fixtures now catch `EPERM` and degrade/skip gracefully, following the existing `createSymlinkOrSkip` convention, while keeping full symlink coverage where symlinks work. Workaround if you cannot update: enable Windows Developer Mode (Settings → Privacy & security → For developers) to grant the file-symlink privilege, or run the suites under WSL/Linux.

Question 3

Why do unsaved AskTool checkbox selections disappear after switching sessions in PI-Desktop?

Accepted Answer

Known bug in PI-Desktop 0.20.1 (still present in v0.21.0-beta.4). The AskTool card keeps draft answers only in component-local `useState` inside `AskToolCard.tsx`. Switching sessions unmounts the card (because `pendingAsk` is filtered by `activeSessionId`), so all checked options reset and the card returns to question 1. The pending ask itself survives in the store, but drafts are not stored anywhere, so nothing can be restored. Workaround: submit the AskTool card before switching sessions — there is no way to recover lost selections once you switch. Permanent fix (for developers building from source): lift drafts out of component state into a per-`requestId` cache, e.g. a `Map` in module scope or an `AskDrafts = Record` slice in `apps/desktop/src/lib/pending-asks.ts` next to the ask queues. Initialise `useState` from the cached draft on mount, write back via `useEffect` on `[drafts, index, request.requestId]`, and delete the entry when the card resolves (including the `ASKTOOL_NOT_FOUND` path) to avoid stale drafts.

Question 4

Why does the activity group auto-collapse and hide tool output when the turn ends?

Accepted Answer

Root cause: in `apps/desktop/src/features/chat/transcript/ActivityGroup.tsx`, the group's open state is bound to `live` (`isActive || topologyLive`), which flips to `false` the moment the turn ends. Since `useAutomaticDisclosure` resolves `open = choice?.open ?? automaticOpen`, any group the user never clicked collapses automatically (multi-tool groups only; single-item groups survive because `visibleItems.length <= 1` stays true). Fix: decouple the group frame from `live` — replace the disclosure call with `useAutomaticDisclosure(hasSubagentTopology ? true : visibleItems.length <= AUTOMATIC_OPEN_MAX_ITEMS, revealRequest, disclosureKey(...))`. Tool rows inside still start collapsed (`ToolRow` uses `useAutomaticDisclosure(false, …)`), and the `DisclosureCollapseRail` still lets users collapse manually. A more general fix is splitting the single boolean into `defaultOpen` (initial state before interaction) and `collapseWhenIdle` (whether to auto-collapse when idle). End-user workaround: click the collapsed group line to re-expand the tool output.

Question 5

Why does the autonomous agent stop mid-task after posting a progress update text?

Accepted Answer

This is a known bug (v0.13.6): the agent-runtime `runLoop` treats any assistant message with zero tool calls as the final answer and emits `agent_end`. When the model follows the system prompt's instruction to write a short progress sentence before the next tool batch—but streams that text with `finish_reason: "stop"` and no bundled `tool_call`—the loop sees `toolCalls.length === 0` and halts the run prematurely. Workaround: manually send a follow-up prompt (e.g., "continue") to resume the task. Proper fixes (choose one): 1) Patch `runLoop` so that in autonomous mode, an assistant message containing text but no tool calls and no explicit task-completion marker triggers one auto-continue/nudge (similar to the existing `pendingSilentTurnRerun`/`SILENT_TURN_NUDGE` recovery in sidecar.js) instead of terminating. 2) Amend the collaboration system prompt to require: "Always emit the tool call in the same message as your text update; never announce an action without the corresponding tool call in the same turn, or execution will terminate."

PI-Desktop

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects