chore: stop passing --no-extensions to the Pi child

[oxwen11]

Requirement

Pie should not start Pi with --no-extensions. Developer request.

Expected behavior

• Pi children (pie-pi-process, live Sessions and get_commands discovery) start with --approve only.
• Extensions load as before: Pi's built-ins (MCP, codemode, tool_search, llama.cpp) and the user's own extensions.
• In-process model listing still loads no extensions.

Changes and risks

• project-resource-policy.ts:
  • PI_PROJECT_PROCESS_ARGS is now ["--approve"].
  • Dropped the comment saying Pie cannot model extension-handled inputs; that is addressed by fix: treat extension commands handled by Pi as non-turn prompts #438.
• agent.test.ts: the fake Pi now rejects --no-extensions instead of requiring it.
• Behavior change: none in practice.
  • pie-pi-process (rpc/main.ts) never read parsed.noExtensions. It always loads builtInExtensions and discovered extensions, so the flag had no effect.
  • Checked against the built bundle: get_commands returns the same commands, including extension commands such as mcp and fff-*, with and without the flag.
  • With the flag, an extension-registered provider (e2e) still answered prompts.
• Left unchanged on purpose: PI_PROJECT_LOADER_OPTIONS.noExtensions for listAvailablePiModels. That runs Pi's SDK inside the daemon, so enabling it would execute extension code in the Pie server process. A consequence is that models registered only by extensions do not appear in the model list. Changing that is a separate decision.

Verification

Tested revision: 6b06ef71.

• Built bundle: get_commands gives identical output with --approve --no-extensions and with --approve, using an isolated PI_CODING_AGENT_DIR that has an extension provider and an MCP config.
• pnpm build and pnpm check pass. Server tests: 638 passed, 1 skipped.
• Not verified: Desktop and Web UI runs. No UI or runtime behavior changes, since the flag was already ignored.

[pkg-pr-new]

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

commit: 3e371d1

[oxwen11]

审查阻塞：领域文档与行为不一致（head 6b06ef71）

代码结论我核实过，成立：rpc/main.ts 从未读取 parsed.noExtensions，resourceLoaderOptions 一直加载 builtInExtensions 和自动发现的扩展，所以去掉 --no-extensions 对运行时没有影响。

阻塞点在 CONTEXT.md 的 Project 条目，它仍然写着：

Automatic Pi extension discovery is disabled for every Pie-owned child … this intentionally makes discovered global and Project extension commands, tools, hooks, and UI unavailable.

这段话是 agent 命名和设计时依赖的领域契约，也直接描述了信任边界：注册一个 Project 之后，是否会执行该 Project 自带的扩展代码。本 PR 删掉了代码里对应的注释，让"Pie 子进程会加载全局和 Project 扩展"成为正式行为，但 CONTEXT.md 没有同步。读这份文档的人会以为 Project 扩展代码不会被执行。

需要做的：

• 在同一 PR 中更新 CONTEXT.md：写明 Pie 子进程加载 Pi 内置扩展、全局扩展和 Project 扩展，注册 Project 即信任执行其扩展代码；同时写明 daemon 内列模型（listAvailablePiModels）仍然不加载扩展。
• 如有必要，同步 docs/ 中的相关安全说明。

完成后从 CI 重新开始审查。另外，#438（扩展命令按非 turn 处理）和 #427（恢复用户扩展加载）与本 PR 是同一主题，合并顺序需要协调。

[oxwen11]

审查意见已处理，未合并。

已在 chore/drop-pi-no-extensions-flag 上普通 merge origin/main（dc8ed6b6，无 force push），并推送 c6f09113。

CONTEXT.md 的 Project 条目现在写明：

• Pie 子进程加载并执行 Pi 内置扩展、全局扩展和该 Project 的扩展。
• 注册 Project 即信任执行其扩展代码。
• daemon 内列模型（listAvailablePiModels）不加载扩展。

docs/ 里没有仍声称“子进程禁用扩展发现”的安全说明。docs/host-persistence.md 只说扩展运行时归 Pi，与现状不冲突，未改。README.md 重复了同一句过时说法（发现已禁用、扩展命令/工具/hooks/UI 不可用），已改成与 CONTEXT.md 一致。

核对过代码：rpc/main.ts 不读 parsed.noExtensions，resourceLoaderOptions 也不设 noExtensions，所以子进程会发现并执行扩展；Project 扩展还要求子进程信任该 cwd（SettingsManager.create 默认信任）。listAvailablePiModels 仍传 PI_PROJECT_LOADER_OPTIONS.noExtensions: true，已有 list-available-models.test.ts 覆盖。

pnpm check 通过（lint、format、typecheck）。全新 worktree 第一次 lint 因未 build、包类型解析成 error 而失败；pnpm turbo run build 之后 pnpm check 通过。

#427 和 #438 仍 open，且与 main 冲突。本 PR 只记录当前子进程行为。#427 还想收紧信任边界（只有显式给出的已注册 Project 才批准 Project 资源，并让显式 --no-extensions 生效）；若它落地，需要再改 CONTEXT.md。#438 只处理已被扩展消费的命令，不改加载策略。建议本 PR 先合，另外两个 rebase 后再对信任措辞。

[oxwen11]

Review and verification record — approved and merged

• Head 3e371d1ad1c245926554c2bbea27e4a870d50e74; base / trusted rules 8cc3ab9bcc06cfcb46acd0b32228438114a5ea87.
• Required CI on this head, all success:
  • Check
  • react-doctor
  • Publish @getpie/cli preview (1, 2)

Review

• My earlier blocker was that the docs still said extension discovery was disabled. Resolved: CONTEXT.md and README.md now state the existing trust model.
  • Pie-owned children load built-in, global and Project extensions.
  • Registering a Project trusts execution of its extension code.
  • The daemon model list loads none.
• Behavior: pie-pi-process (rpc/main.ts) never read the flag. Its resourceLoaderOptions always add builtInExtensions plus discovered extensions. On this head no source under packages/server/src references --no-extensions. Removing it therefore changes argv only.
• Security: there is no new trust grant. Children already executed this extension code. The in-daemon SDK path (PI_PROJECT_LOADER_OPTIONS.noExtensions) is unchanged, so extension code still does not run inside the daemon process.

Independent verification

Clean worktree at this head, locked install, Turbo build of server + CLI.

• agent.test.ts: 24 passed. The fake Pi now exits if --no-extensions is present.
• CLI daemon: isolated PIE_HOME on its own port, real model through the operator's Pi config. No explicit model was used, so the shared Pi default was not written.
  • Doctor: OK.
  • pie run on a sample Project produced a real turn. The pi-process child argv was --mode rpc --session-id … --approve --extension <bundled fff>, with no --no-extensions.
  • The model's tool list included extension-provided tools (codemode, plus grep/find from the bundled fff extension). Extensions load as the PR describes.
• Cleanup: the owned daemon was stopped and the port released; evidence was kept locally.
• Gaps:
  • No same-run baseline on main. Equivalence rests on the source reading above.
  • No Web/Desktop UI run. Not needed: this change has no UI surface.

[oxwen11]

Merged as c020c97 (squash, head guard 3e371d1a); follows the record above.