fix(desktop): give Pi channel tasks their workspace and repo tools - #92776
Conversation
A repo-less Pi task runs in an empty per-task scratch directory. The desktop host registered only the context-wiki extension for it, so `list_repos` and `clone_repo` were absent and the agent could not reach any code. The prompt also chose its channel guidance from a capability flag the Pi harness never set, so it fell back to the short variant that names neither tool. The RPC host now derives one answer for both. It resolves the task context first, adds the repository tools when the task is a channel task, and passes the resulting capability to the prompt builder. Resume drops `channelMode` from the bootstrap payload, so the resolved context is the only reliable source. The channel prompt also states the working directory path, which previously appeared only as a single line at the end of Pi's own base prompt. Generated-By: PostHog Desktop Task-Id: c2d94e28-1a90-4537-9cb7-9c05cad5a641
|
😎 Merged successfully - details. |
🦔 PostHog Review reviewed this pull requestFound 0 must fix, 2 should fix, 0 consider. Published 2 findings (view the review). Resolved comments: 2 fixed |
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
🤖 CI report✅ Trunk lane — non-backend laneThis PR is assigned to the non-backend lane. It does not run backend Python tests and may merge in parallel with PRs in other lanes. |
There was a problem hiding this comment.
Approved.
Contained, well-tested fix to the desktop Pi harness's tool/extension wiring and prompt text; no risky-territory surface (no auth, billing, crypto, public API, CI, migrations, or dependency changes) and the diff matches the description with new tests covering each behavior change.
- 5 of the 5 changed files are governed by
products/desktop/AGENT_APPROVALS.md.
Gate mechanics and policy version
| Gate | Result | |
|---|---|---|
| prerequisites | ✓ | all clear |
| deny-list | ✓ | no deny categories matched |
| size | ✓ | 39L, 3F substantive, 73L/5F incl. docs/generated/snapshots — within ceiling |
| tier | ✓ | T1-agent / T1b-small (73L, 5F, single-area, fix) |
| stamphog 2.0.0b4 | .stamphog/policy.yml @ c4c5b36 · reviewed head c4c5b36 |
HostHog preview —
|
|
PostHog Review alpha 🦔 If you find any issues helpful - please reply "valid", "invalid", etc., for evaluation purposes 🙏 |
The list_repos handler shelled out with execFile and no timeout, so a stalled gh network request kept the tool call, and the Pi turn awaiting it, pending with no recovery. Route it through execGh with a finite timeoutMs, matching the sibling clone_repo tool, and surface a timeout through the existing tool-error result. The gh token env handling is unchanged: execGh merges the token overrides onto process.env. Generated-By: PostHog Desktop Task-Id: 60c58075-3434-4ef3-a3d2-e96193b49780
A new stamphog review started for this PR — the fresh verdict replaces this approval.
There was a problem hiding this comment.
Not approved — this change needs a human reviewer.
Re-add the stamphog label to request another review once you have addressed this.
An unresolved reviewer comment flags that the cloud repo-less Pi prompt still omits the repository tools because the channel-prompt section is gated on context.channelMode, which the cloud task-context construction never sets — checking the code confirms this gate is unchanged and the new tests only exercise the channelMode: true case, so the PR's own claim to have fixed the cloud path does not hold.
- 6 of the 6 changed files are governed by
products/desktop/AGENT_APPROVALS.md. - Unresolved @PostHog[bot] review comment on task-system-prompt.ts: cloud repo-less Pi tasks register repository-tools but buildTaskSystemPrompt only appends the channel prompt (which names list_repos/clone_repo) when context.channelMode is true; pi-agent-server.ts's cloud TaskContext never sets channelMode, so the prompt/tool mismatch this PR claims to fix on the cloud path persists.
- No test added covers the channelMode:false + repositoryTools:true combination that reproduces the still-open cloud bug; existing new tests only vary capabilities under channelMode:true.
Gate mechanics and policy version
| Gate | Result | |
|---|---|---|
| prerequisites | ✓ | all clear |
| deny-list | ✓ | no deny categories matched |
| size | ✓ | 60L, 4F substantive, 94L/6F incl. docs/generated/snapshots — within ceiling |
| tier | ✓ | T1-agent / T1c-medium (94L, 6F, single-area, fix) |
| stamphog 2.0.0b4 | .stamphog/policy.yml @ a4f94fd · reviewed head a4f94fd |
A repo-less cloud Pi run registered list_repos and clone_repo but the system prompt never described them: the channel section is gated on channelMode, and the cloud task context never set it. The agent held tools it was never told about. Derive channelMode from the existing repo-less condition once, set it on the cloud task context, and reuse it for the repository-tools extension registration. Tool registration is unchanged (same condition as before); the prompt now names the tools whenever they are registered, so the two can no longer disagree. Generated-By: PostHog Desktop Task-Id: 60c58075-3434-4ef3-a3d2-e96193b49780
There was a problem hiding this comment.
Approved.
Contained desktop-agent bugfix (Pi channel tasks now get repo tools consistently with what the prompt describes) with new unit-test coverage; the one flagged reviewer concern about the cloud repo-less path is verifiably fixed in the current diff (channelMode is now set on the cloud TaskContext and flows through to the prompt builder), and the change doesn't touch auth, billing, migrations, public APIs, or CI/deploy config.
- 7 of the 7 changed files are governed by
products/desktop/AGENT_APPROVALS.md. - The inline review thread flagging the cloud repo-less path is still marked unresolved on GitHub, though the current diff appears to address it (channelMode is now included in pi-agent-server.ts's TaskContext) — worth a human double-check that the thread gets marked resolved.
- list-repos.ts changes how GH tokens are passed to the gh subprocess (via a shared execGh helper) — low risk since it's a mechanism swap with an added timeout, not a scope change, but not independently verifiable from this checkout.
Gate mechanics and policy version
| Gate | Result | |
|---|---|---|
| prerequisites | ✓ | all clear |
| deny-list | ✓ | no deny categories matched |
| size | ✓ | 67L, 5F substantive, 101L/7F incl. docs/generated/snapshots — within ceiling |
| tier | ✓ | T1-agent / T1c-medium (101L, 7F, single-area, fix) |
| stamphog 2.0.0b4 | .stamphog/policy.yml @ f116d13 · reviewed head f116d13 |
Deploy status
|
Problem
list_reposandclone_repotools are never created.repositoryToolscapability that the Pi harness never sets. Pi therefore always gets the short variant, which names neither tool. Claude passes the flag and gets the full variant.Reported in a Discord bug thread as Pi missing the current directory and other harness functionality.
Changes
list_reposandclone_repowhenever those tools exist, and stays silent about them when they do not. Tools and the text that describes them can no longer disagree.rpc-hostresolves the task context before it builds the extension list. Resume dropschannelModefrom the bootstrap payload, so the resolved context is the only source that survives a restart. Gating in the desktop factory instead would silently lose the tools on every resume.createPiTaskSystemPromptExtensiontakes an optional capabilities argument and forwards it, andbuildChannelPrompttakes the working directory.How did you test this code?
Automated tests only. This change was not exercised against a running desktop app.
packages/agent:src/pisuite, plus new cases intask-system-prompt.test.tsandtask-system-prompt-extension.test.ts.packages/workspace-server:src/services/agent/agent.test.ts, which covers the Claude caller of the shared prompt builder.packages/agenttypecheck.New tests and what each catches:
buildTaskSystemPromptcase: the channel prompt promisinglist_reposwhen no harness registered it, or hiding it when one did. No existing test varied the capability.Not checked: whether
clone_reposucceeds end to end on a desktop machine withoutghinstalled. The tool reports its own error there, the same as it does for Claude.Automatic notifications
Docs update
None. No doc under
products/desktop/docsdescribes channel tasks or these tools.🤖 Agent context
Autonomy: Fully autonomous
Investigated with Claude Code via a PostHog inbox report. Skills invoked:
/writing-tests,/writing-user-facing-copy,/writing-code-comments,/writing-pr-descriptions,/simplify.The report bundled four asks: the current directory, a goal command, plan mode, and build mode. Only the workspace gap turned out to be a defect in this repository, and that is all this PR changes.
Considered gating the repository tools in the desktop client factory instead. Rejected: the resume path does not carry
channelMode, so the tools would vanish whenever a session restarted.Nothing in this PR carries material from the agent session. The change is code and tests written against this repository.
Created with PostHog Desktop from this inbox report.