chore: upgrade pi coding agent to 1.0.2

[oxwen11]

Requirement

Upgrade @earendil-works/pi-coding-agent / pi-tui from 0.99.1 to 1.0.2 (picks up the brace-expansion advisory fix in 1.0.1 and "model at capacity" retries). Follows the shape of #426.

Expected behavior

No Pie-visible behavior change beyond upstream Pi fixes. New sessions, chat turns, tool calls, compaction and resume keep working through the bundled pie-pi-process.

Changes and risks

• pnpm-workspace.yaml: catalog.pi pins → 1.0.2; patchedDependencies key → @1.0.2.
• Patch regenerated with pnpm patch / patch-commit as @earendil-works__pi-coding-agent@1.0.2.patch. Content is identical; only the git blob index lines changed.
• Upstream dist/modes/rpc/*, json-event, and output-guard are byte-identical between 0.99.1 and 1.0.2, so the vendored RPC files only bump their Vendored from headers. The only upstream main.js change is that --provider now requires --model. Pie uses its own rpc/main.ts and always passes both.
• Public SDK type changes are additive only.
• Lockfile: Pi family 1.0.2, @anthropic-ai/sdk 0.129.0, brace-expansion 5.0.12; @ff-labs/pi-fff@0.10.6 still resolves against the catalog. Unrelated drift: react-scan declares react-doctor: "latest", so any re-resolve adds react-doctor@0.9.17 for react-scan only (dev tooling). apps/app stays on 0.9.14. I could reproduce it deterministically from a clean main checkout.
• Upstream behavior changes that come along (Pie loads builtInExtensions): MCP tool and namespace names now use _ instead of -; MCP servers connect in the background; deferred MCP tools are restored after reconnect on resume; MCP OAuth credentials are now keyed by server name + URL (1.0.0 migrates Pi-global auth files). None were exercised against real MCP servers. See below.

Verification

Tested revision: 1bfa8dfd (macOS arm64, Node 24.19, Bun 1.4.2).

• pnpm build: pass. pnpm check: pass.
• pnpm test (node): 197 files / 1340 tests pass, including rpc-bundle.test.ts (VERSION 1.0.2, xai/bedrock auth loading, extension input routing) and bundled-node.test.ts, against the freshly built bundle.
• pnpm test (browser): 99/100. The one failure, slash-command-menu.test.tsx > keeps modified and composing Enter out of command selection, also fails on unmodified main (pre-existing).
• pnpm e2e (Desktop): chats through the real Pi process with the e2e provider and the multi-client sync specs pass. The failing desktop-rpc.spec.ts cases (background render, server-crash banner, Retry, terminal-failure quit) also fail on unmodified main locally (environmental/pre-existing).
• Web runtime (pie-verify web, isolated PIE_HOME, isolated PI_CODING_AGENT_DIR seeded with a fake provider extended to emit a bash tool call): new chat in the sample project → the tool call ran (pie-tool-ok toolResult in the transcript) → assistant reply rendered. Before/after screenshots and video are attached in a comment.
• Bundle-level RPC against the built 1.0.2 pie-pi-process (isolated agent dir): 3 turns incl. a tool call → manual compact succeeded (compactionSummary entry) → a further prompt works. Then a fresh process with --session-id resumed that session: history including the compaction summary was restored, and a new tool-call turn completed.

Additional verification (details and per-runtime tables in the PR comments):

• MCP (isolated agent dir, local stdio and OAuth fixtures): _ tool names; background connect (the first prompt is not blocked by an 8 s server); legacy mcp-auth.json migrated to mcp__<name>|<url>; per-server sign-in with RFC 9207 iss and PKCE; credentials reused after resume. The same harness fails these on upstream 0.99.1, so it does distinguish the versions.
• MCP OAuth through the Pie web UI: /mcp login opened the system browser against the local fixture authorization server. Sign-in completed and the tool then worked.
• Real model (the user's default xai/grok-4.7 via the shared ~/.pi/agent, run with the user's approval):
  • Web chat with a real bash tool call.
  • CLI pie run → daemon restart → resume keeps context.
  • Manual compaction with a real summary → daemon restart → resume keeps context.
• Packaged app: electron-builder --dir output contains a pie-pi-process.js byte-identical to the tested bundle. Running it with the vendored Bun completes a tool call and compaction.

Known issues, pre-existing and the same on main/0.99.1, not caused by this PR:

1. Extension slash commands such as /mcp and /mcp login … get { started: false } from Pi. process.ts turns that into "Model request failed: Pi queued a prompt without an active server turn", although the command itself succeeded.
2. Deferred MCP tools loaded by tool_search are dropped when a session resumes. This happens on upstream Pi 0.99.1 and 1.0.2 RPC as well; the 1.0.0 changelog fix does not apply in RPC mode.
3. Locally on main as well: the browser test slash-command-menu › modified Enter and some desktop-rpc.spec.ts E2E cases fail. CI is green.

Compatibility: Pi ≥ 1.0 moves URL-keyed MCP OAuth entries in $PI_CODING_AGENT_DIR/mcp-auth.json to name+URL keys. A Pie or pi older than 1.0 that uses the same agent dir, including after a rollback, must sign in to those MCP servers again. This data is Pi-owned per docs/host-persistence.md.

[oxwen11]

Web runtime evidence @ 1bfa8df (isolated PIE_HOME + isolated PI_CODING_AGENT_DIR, fake provider with bash tool call): before = new draft in sample project; after = tool-call turn completed with assistant reply; video shows the full drive.

recording-001.webm

[pkg-pr-new]

npx https://pkg.pr.new/oxwen11/pie/@getpie/cli@433

commit: 5f09ea8

[oxwen11]

Follow-up verification @ 1bfa8df: MCP behavior and Pie daemon resume

All runs used an isolated PI_CODING_AGENT_DIR with the fake provider, local MCP fixtures, and a local loopback OAuth authorization server (DCR, PKCE S256, RFC 9207 iss, auto-approve). Nothing ran against real servers or credentials.

Same harness on three runtimes (pie-pi-process 1.0.2 bundle / upstream Pi 1.0.2 RPC / upstream Pi 0.99.1 RPC):

Check	Pie bundle 1.0.2	upstream 1.0.2	upstream 0.99.1
First prompt not blocked by a slow (8 s) codemode server	pass (≈0.5 s)	pass	fail (8.7 s)
MCP tool names use _: mcp__dev_tools__say_hello	pass	pass	mcp__dev-tools__say-hello
Direct MCP tool call	pass	pass	n/a (old names)
Legacy URL-keyed mcp-auth.json moved to mcp__<name>|<url> and used	pass	pass	stays URL-keyed
Same URL, other server name → separate sign-in (/mcp login), RFC 9207 iss present, PKCE verified	pass	pass	—
Credentials stored per name+URL; reused after resume	pass	pass	—
tool_search loads deferred tool; callable	pass	pass	—
Resumed session (--session-id) keeps the deferred tool that tool_search loaded	fail	fail	fail

Through Pie itself (pie-verify cli, isolated PIE_HOME; the env is re-applied on every daemon start): pie run + pie send ran a direct MCP call, an OAuth MCP call (legacy credentials migrated, as the table shows), and a tool_search-loaded deferred call. Then daemon stop → daemon start → pie send resumed the same Pi session (one transcript file). The direct and OAuth calls work again. The deferred tool returns Tool … not found. That matches upstream Pi 0.99.1 and 1.0.2, so it is not a regression from this PR. The 1.0.0 changelog entry ("deferred MCP tools restored after reconnect on resume") does not hold in RPC mode, even with a 12 s wait for servers to reconnect.

Correction to the PR description: the "resume via daemon restart hangs" note was a harness artifact. PI_CODING_AGENT_DIR was not re-exported for the restarted daemon. With it re-applied, resume works on 1.0.2.

Compatibility note (Pi-owned data, per docs/host-persistence.md): with Pi ≥ 1.0, the first load moves URL-keyed MCP OAuth entries in $PI_CODING_AGENT_DIR/mcp-auth.json to mcp__<name>|<url> and deletes the old key. Pie (or a standalone pi) on Pi < 1.0 sharing the same agent dir will no longer find those credentials and needs to sign in again. This also applies after a rollback.

Still open: a real-model run and the OAuth sign-in through the Pie UI (it launches the system browser).

[oxwen11]

Real-model and UI OAuth evidence @ 1bfa8df.

• real-model-before/after: Pie web chat on Pi 1.0.2 with the user's default model (xai/grok-4.7, shared ~/.pi/agent, approved). The transcript shows bash toolCall → toolResult pie-real-ok-1.0.2 → reply.
• oauth-*: isolated agent dir with a local fixture authorization server.
  1. Before sign-in, the tool is missing.
  2. /mcp login dev-oauth signs in successfully, but Pie shows the pre-existing 'Pi queued a prompt without an active server turn' error. Main/0.99.1 returns the same {started:false} admission.
  3. After sign-in, the tool returns secure hello.
     Each recording covers the corresponding run.

recording-001.webm

recording-001.webm

[oxwen11]

Rebase was reset

GitHub rebase onto current main produced a9141baf (parent dd85b29a). Required Check on that head succeeded: https://github.com/oxwen11/pie/actions/runs/37290550204

At 2026-10-05T09:36:56Z the branch was force-pushed back to 1bfa8dfd, which is behind main again. I am not pushing it back over that reset. This version still needs a current-base update before review or merge.

[oxwen11]

auto-merge: no

head 1bfa8dfd8004 — required CI green (Check, react-doctor, both Publish @getpie/cli preview, Continuous Releases, React Doctor), MERGEABLE (BEHIND main f6912c31e83b), but fails the exclusions:

• Exclusion (runtime dependency upgrade): pnpm-workspace.yaml and pnpm-lock.yaml bump @earendil-works/pi-coding-agent and @earendil-works/pi-tui from 0.99.1 to 1.0.2 (a major-version line change of the embedded agent runtime), and the patch file moves to patches/@earendil-works__pi-coding-agent@1.0.2.patch with new contents.
• Exclusion (non-presentational change): the vendored RPC sources under packages/server/src/harness/pi/rpc/ (main.ts, rpc-mode.ts, rpc-types.ts, jsonl.ts, json-event.ts, output-guard.ts) are re-synced to 1.0.2, which touches the server's Pi RPC protocol path, not only the version header comments.
• Docs/tooling group only allows root package.json/lockfile changes for oxlint/oxfmt and their plugins, so it does not cover this bump.

Needs human review (and ideally a real session smoke on 1.0.2). Not merged.

[oxwen11]

Merged current main; persistence inventory updated. Not merged.

Head is 5f09ea83. Fast-forward push only (no force). Merge commit 8aba4390 is a normal merge of origin/main (580ec562, includes #424). The auto-merge of rpc-mode.ts / rpc-types.ts kept main's prompt disposition field and the 1.0.2 vendored headers.

docs/host-persistence.md:

• Daemon cold transcript open on Pi 1.0.2 matches 0.99.1, so there is no new open side effect. Compared the installed packages: dist/core/session-manager.js, dist/core/messages.js, and dist/utils/paths.js are byte-identical, and the config.js exports open uses (getAgentDir, getSessionsDir, APP_NAME) are unchanged. The Pie patch does not touch those files. A Pi newer than 1.0.2 still needs its own persistence decision.
• Pi-owned writes now record the Pi 1.0 $PI_CODING_AGENT_DIR/mcp-auth.json migration: URL-only keys move to name+URL keys (mcp__<name>|<url>, - in the name replaced by _) when that server first loads the legacy entry. The first server with that URL takes the credentials. Rolling back to a Pie or pi older than 1.0, on the same agent dir, must sign in to those MCP servers again.

Verification on 5f09ea83 (macOS arm64):

• pnpm check: pass (lint:check, format:check, typecheck).
• Affected server tests: 8 files / 94 tests pass (session, session-service, pi-agent, pi/agent, session-tools-composition, rpc-bundle, handshake, worktree).

Please re-review from CI. I am not merging.

[oxwen11]

审查与独立验证记录：通过

• Head 5f09ea835ab3ceeb69f3b751eaaac6021f28d8f8。Base / 可信规则 commit：main 580ec5626ef448a7fceff6f7600a01214d3f0f4b，已包含 fix(server): load session history without starting a Pi process #424。
• CI：当前 head 的必需检查全部 SUCCESS，包括 Check、react-doctor 和两项 Publish preview。

审查

• Pi 系列包从 0.99.1 升到 1.0.2，补丁内容不变。vendored RPC 文件只改了 Vendored from 头。
• fix(server): load session history without starting a Pi process #424 的持久化清单规定，新版本 Pi 的 open 如果有新副作用，就要重新做决策。我把 npm 上 0.99.1 和 1.0.2 两个包解开比对过：
  • dist/core/session-manager.js 字节相同；它依赖的 messages.js、utils/paths.js 也相同。
  • config.js 中被用到的 getAgentDir、getSessionsDir、APP_NAME 没有变化。
  • 结论：1.0.2 没有新增 open 副作用。本 PR 已在 docs/host-persistence.md 中写明这一点。
• 同一文档还登记了 Pi 1.0 对 $PI_CODING_AGENT_DIR/mcp-auth.json 的迁移：URL 键改为 name+URL 键，回滚到 1.0 之前需要重新登录 MCP。这份数据归 Pi 所有，Pie 不读写它。
• 安全：依赖升级本身包含 1.0.1 的 brace-expansion advisory 修复，没有新增信任边界。
• 备注：feat(server): background long bash commands after 60 seconds #390 修改的是 0.99.1 的 patch，本 PR 合并后它需要把导出移到 1.0.2 的 patch 上。

独立验证

在 reviewer 自己的 worktree 中检出该 head，执行 pnpm install --frozen-lockfile，再用 Turbo 构建 server 和 CLI。打包出的 pi-process 版本为 1.0.2。

• 测试：rpc-bundle.test.ts 共 3 个测试，全部通过。
• 运行时：用 pie-verify cli 起隔离 PIE_HOME 的 daemon，使用操作者现有的 Pi 配置和真实默认模型，未传 --provider/--model-id，所以没有改写 Pi 的全局默认值。本机没有 mcp-auth.json，因此不触发 MCP 凭据迁移。

## turn 1 (Pi 1.0.2, real model, bash tool)
user	Use the bash tool to run: echo pie-tool-ok-102 > marker.txt && cat marker.txt . …
assistant	pie-tool-ok-102          # marker.txt 实际写入了 pie-tool-ok-102
## daemon stop → start, then cold read
assistant	pie-tool-ok-102          # 历史完整，daemon 子进程只有 resource-monitor
## resumed turn after restart
user	What exact text did marker.txt contain? …
assistant	pie-tool-ok-102

以上覆盖了：真实工具调用、daemon 重启后用 1.0.2 冷读 transcript、恢复会话后继续对话。

未覆盖：没有在本机复测 compaction 和 MCP OAuth，作者已在 PR 中提供隔离 fixture 的证据。

结论：通过，可以合并。如果 head 或 base 变化，从 CI 重新开始。

[oxwen11]

已合并（squash，stack 底层 PR 通过 merge-async 合并，并校验 expected_head_sha）。merge commit 为 8cc3ab9bcc06cfcb46acd0b32228438114a5ea87，合并时的 head 为 5f09ea83。审查与验证记录见 #433 (comment) 。