[chubes4]

Related issues

• Continues the Studio Code prompt and runtime work (Studio Code: Drop the payload-limit prose the Write, Edit and Bash refusals already carry #5162, Studio Code: Give the agent its WordPress.com site's plan features instead of describing plan tiers #5170, Studio Code: Drop the prompt rules that repeat the file tools' own guidance #5189, Studio Code: Drop the plan guardrail that repeats the hosting-plans-helper skill #5190, Studio Code: State the active site in the system prompt instead of prepending it to every message #5192, Studio Code: Bring the remote-site runbook with a WordPress.com active site instead of a rule to load it #5231, Studio Code: Refuse writes to a Studio site's WordPress core instead of forbidding them in the prompt #5164): Studio builds on pi's own primitives instead of switching them off.

How AI was used in this PR

Claude (via the Pi coding agent in a Roadie session) traced how Studio Code configures pi's resource loader, made the change, wrote the tests, and ran the checks below. I reviewed the diff.

Proposed Changes

Studio Code runs on pi but turns its extension system off (noExtensions: true since #3360), so the only way to change the agent's tools, providers or prompt is to change Studio. This turns it on.

• Studio Code sessions load pi extensions from ~/.studio/agent/extensions, the same way pi loads ~/.pi/agent/extensions. An extension uses pi's API as is:
  • pi.registerTool() adds a tool. Studio now enables extension tools next to its own; before, the session's tool allowlist only named Studio's.
  • pi.on( 'before_agent_start' ) extends the system prompt on each turn.
  • pi.registerProvider() registers a provider. Picking an extension's model in Studio is a follow-up.
• New getAgentDirectory() (~/.studio/agent) in well-known-paths. pi's agent directory was the sites root (~/Studio), which is the wrong home for extensions/. The sites root stays the session's working directory and stays untrusted, so project-level extensions (~/Studio/.pi/extensions) do not load.
• An extension that fails to load is reported with console.warn and skipped, and the turn runs without it.

Extension tools are the user's own code, run with the user's permissions, as in pi. Studio's guards (payload limits, core-file refusal) stay on Studio's own Write, Edit and Bash; they do not wrap extension tools.

Testing Instructions

• npx vitest run apps/cli/ai packages/common/lib: 925 passed, 1 skipped. New tests:

  • an extension in the agent directory loads, keeps its before_agent_start handler, and its tool is enabled next to Studio's;
  • a broken extension is reported and skipped.

• Live, through the WordPress.com AI proxy, with a temporary config directory holding agent/extensions/motto.js. The extension registers a studio_motto tool and appends a section to the prompt that says to use it for the team motto. The prompt was "What is our team motto?":

  Build	Result
  This branch, 2 runs	Proxy admitted the turn; agent called studio_motto and quoted "code is poetry, ship it kumquat-7." (23.9k tokens)
  Trunk, same config	Extension not loaded; agent searched local sites for a motto and timed out

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing 391d677 vs trunk

app-size

Metric	trunk	391d677	Diff	Change
App Size (Mac)	944.37 MB	944.37 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	391d677	Diff	Change
load	1234 ms	1232 ms	2 ms	⚪ 0.0%

site-startup

Metric	trunk	391d677	Diff	Change
siteCreation	7062 ms	7079 ms	+17 ms	⚪ 0.0%
siteStartup	4371 ms	4371 ms	0 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[youknowriad]

Why do we want to do that? We're using pi as a framework and I'm not sure we should allow pi extensions.

[chubes4]

I am picturing that Studio should have the freedom and extensibility of WordPress itself.

This was a first step towards enabling users to bring their own model or provider to Studio. It would also let users add their own tools and extend the system prompt.

However it wouldn't actually enable BYO because our providers list is still closed. So it's more of a primitive capability than anything else.

I set it back to draft, as I think it's premature compared to some of the other changes that need to be made.