[Bug]: Stale ACP registry cache pins Factory Droid to 0.233.0, whose session/new crashes on any mcpServers; no update surfaced #18305

Summary

T3 keeps Factory Droid pinned to 0.233.0 via a stale cached ACP registry index, and 0.233.0 cannot open any session through T3 because its session/new worker crashes whenever mcpServers is non-empty — which it always is, since T3 attaches its t3-code bridge. The live registry already lists 0.238.0, in which I verified the full session-open sequence works. Nothing in T3 refreshes the index or tells the user an update exists, and the failure message hides the actual cause.

Environment

• T3 Code (Nightly) desktop 0.0.46-nightly.20261011.2980, macOS arm64
• Managed install: droid@0.233.0 at ~/.t3/tools/factory-droid/0.233.0
• Local index cache ~/.t3/caches/acp-registry/registry.json dated Oct 5 → factory-droid 0.233.0; live index at https://cdn.agentclientprotocol.com/registry/v1/latest/registry.json → factory-droid 0.238.0 (checked Oct 11)

Evidence (all reproduced locally)

1. delegate_task with acpRegistry_factory_droid fails with Failed to open acpRegistry provider session .... Provider log shows initialize: succeeded, then session/new: failed (errorTag: AcpRequestError) retried 5x. Droid's own log (~/.factory/logs/console.log) shows the real cause: Droid process exited unexpectedly (exit code 1).
2. Replaying the exact captured session/new (cwd + the single t3-code acp-mcp-bridge entry) against the managed 0.233.0 binary reproduces the exit-1 crash. mcpServers: [] succeeds. A trivial self-written stdio MCP server also crashes it — so this is not about the bridge, cwd, auth, or skills; 0.233.0 cannot handle any mcpServers.
3. Same payloads against droid 0.238.0 (from Factory.app): session/new succeeds, and session/set_config_option for model, reasoning_effort, autonomy_level all return proper configOptions (i.e. the [Bug]: Factory Droid sessions fail for every selected model because session/set_config_option returns no configOptions #16454 bug is also fixed there).
4. Manually upgrading T3's managed copy to 0.238.0 gets reverted within a minute: readPackageReceipt enforces installed-manifest == pinned version, so local upgrades cannot stick.

Relevant code (main)

• packages/provider-acp-registry/src/server/AcpRegistrySupport.ts: loadRegistry is cache-first (loadCachedRegistry, ~line 874); only the search/add-update flows call refreshRegistry (~lines 1577, 1622). Session open therefore keeps resolving the stale pin.
• packages/provider-acp/src/server/adapter.ts: acpMcpContext (~line 680) attaches the bridge to every session with an MCP credential, so the 0.233.0 crash is unavoidable on the pinned version.
• ProviderSessionManagerV2LayerOptions.configureMcp is test-only; there is no user-facing way to omit the bridge.

Related

• [Bug]: Factory Droid sessions fail for every selected model because session/set_config_option returns no configOptions #16454 (closed, fix-belongs-in-Droid) and its duplicate Factory Droid ACP thread hangs before the first response #17108: the set_config_option {} bug — fixed upstream in 0.238.0.
• [Bug]: ACP provider session fails to open - acpRegistry_cline throws "Provider session failed to open" mid-session #17072: same error string, different (Cline-specific) cause.
• PR fix(server): provider session failures show the provider's reason #14969 (open): surface the provider's reason on session failures — would have saved most of this debugging; users currently see only Failed to open acpRegistry provider session ....

Ask

1. Refresh the ACP registry index on the existing provider-update-check cadence (or at least when opening a registry-agent session finds a skew), and surface registry-agent updates in Settings → Providers. The supported recovery today (provider update/reinstall, which hits prepare → refreshRegistry) is undiscoverable.
2. Include the underlying provider reason in Provider session failed to open errors (per fix(server): provider session failures show the provider's reason #14969).

Workaround for other readers

Settings → Providers → Factory Droid → update/reinstall, so T3 fetches the current index and installs droid@0.238.0. Verified at the protocol level; droid CLI auth itself is fine (droid doctor passes).