[Bug]: Pi text generation fails for models that a Pi extension adds, even though the model picker offers them#19053

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Create a Pi extension that adds a provider, for example ~/.pi/agent/extensions/demo-provider.ts:

   ts

   1	import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";
   2
   3	export default function (pi: ExtensionAPI) {
   4	pi.registerProvider("demo", {
   5	baseUrl: "http://127.0.0.1:9/v1",
   6	apiKey: "unused",
   7	api: "openai-completions",
   8	models: [{
   9	id: "demo-model", name: "Demo Model", reasoning: false, input: ["text"],
   10	cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
   11	contextWindow: 128000, maxTokens: 4096,
   12	}],
   13	});
   14	}

   Real setups do the same through provider packages listed in settings.json packages.

2. In T3 Code, open Settings and set the text generation model to Pi → demo/demo-model. The picker lists it because model discovery runs Pi with extensions loaded.

3. Start a new Pi thread and send a message.

The Pi step alone reproduces it, outside T3:

Expected behavior

The text generation model setting and the Pi process that text generation launches agree on which models exist. Either text generation can use a model the picker offers, or the picker does not offer models that text generation cannot load and says why.

Actual behavior

Every Pi text generation request fails at set_model. That includes thread titles, commit messages, PR content and branch names. The thread keeps its truncated first-message title.

Cause, on main @ 6524a8d:

• Model discovery, packages/provider-pi/src/server/status.ts makePiDiscoveryConnection, calls buildPiRpcLaunch without disableExtensions. Extension-registered providers load and their models are listed.
• Text generation, packages/provider-pi/src/server/textGeneration.ts, passes disableExtensions: true, so Pi starts with --no-extensions --no-tools. --no-extensions also skips the provider packages in Pi's settings.json, so the provider does not exist and set_model fails. The comment there says "User model config and auth still apply", which holds for models.json providers but not for extension-registered ones.

The disableExtensions: true choice itself makes sense, because no user is present to answer an extension dialog. The two launches just disagree about the model catalog.

Verified: the Pi RPC repro above on Pi 1.1.0, and the matching server log line on the nightly. Not verified: the full T3 UI flow with the demo extension; I observed it with a real extension-registered provider.

Impact

Major degradation or frequent failure

Version or commit

t3 0.0.46-nightly.20261012.3010; code paths unchanged on main @ 6524a8d

Environment

Linux x64, t3 server mode, Pi 1.1.0, text generation provider: Pi with an extension-registered provider

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response