Managed Environments: upstream's ChatGPT handoff runs a Codex sign-in outside the row 18 guard

What

On a managed Environment, row 18 of the overlay ("providers sign in through Lazurio") refuses Codex sign-in inside T3: LazurioProviderSignIn wraps ProviderAuthService.start and importProfile and refuses them for a Codex instance (apps/server/src/lazurio/providerSignIn.ts).

Upstream's ChatGPT handoff, WS_METHODS.chatGptHandoffSubscribe (apps/server/src/ws.ts, provider/CodexChatGptHandoff.ts), is a separate path. It runs a ChatGPT sign-in in the T3 server's memory and exports the profile to the client, without going through ProviderAuthService.start, so the guard does not see it.

Why it matters

Codex on a managed Environment can only use that profile through importProfile, which the guard refuses, so the sign-in cannot replace the Environment's own Codex sign-in. But the token still passes through the T3 server, which the decision behind row 18 (provider credentials stay with Lazurio, not with T3) wanted to avoid.

This is not new: the handoff exists unchanged since v0.1.3. It was found in the inventory of the v0.1.4 rebuild (#143) and left out of that rebuild because it widens row 18.

Question

Should the guard also refuse chatGptHandoffSubscribe when the target instance is Codex on a managed Environment (and the UI hide the entry that starts it)? If yes, it belongs in row 18 at a later rebuild or as a regular overlay fix on main.

Found by the T3 Release bot while rebuilding onto v0.1.4.

Plan for the v0.1.5 rebuild, before its canary (from the independent review of the v0.1.4 dry run, #144). The dry run leaves this as it is: v0.1.4 did not make it worse.

Server. Refuse WS_METHODS.chatGptHandoffSubscribe (apps/server/src/ws.ts:2470-2471) whenever config.lazurioFolder is set (apps/server/src/config.ts:94), that is, on every Lazurio Environment, in the same row 18 layer that refuses ProviderAuthService.start and importProfile (apps/server/src/lazurio/providerSignIn.ts). A test that fails without the refusal.
Web. Hide the handoff entry in CodexSetupSection (apps/web/src/components/settings/CodexSetupSection.tsx:283-290) when the primary Environment is a Lazurio Environment, so the person never starts a sign-in the server refuses.

Why not the check this issue first suggested ("when the target instance is Codex on a managed Environment"): the handoff's input names the instance and the Environment that will receive the profile (ChatGptHandoffInput { instanceId, environmentId, … }, packages/contracts/src/providerSetup.ts:223-229). The server that runs the sign-in cannot resolve another Environment's instance, so the check has to be "this server is a Lazurio Environment", not "the target is Codex". Not verified yet: whether some upstream path lets a server look up a peer's instance kind; the v0.1.5 inventory checks it.

Tracked in the v0.1.5 rebuild as a gate before canary (fix, or an Admin decision recorded in the rebuild issue).

— T3 Release (bot)

Fixed in row 18 of the v0.1.6 rebuild, #152 (head 0ddf6f4628). ws.ts routes chatGptHandoffSubscribe through LazurioProviderSignIn.handoff, which fails with LAZURIO_CHATGPT_HANDOFF for every instance whenever T3CODE_LAZURIO_FOLDER is set (apps/server/src/lazurio/providerSignIn.ts). The guard also refuses reconnectProfile for a Lazurio Environment's Codex, and the web starts no handoff through a Lazurio primary. A server test and the release contract test pin the refusal and its wiring; reverting either makes them fail (mutations recorded in #148).

This stays open until main carries the fix.