Chat unexpectedly resets to Ask across harnesses during mode availability changes #338501

Summary

Users report that Chat unexpectedly resets to Ask in both the Local and Copilot/Agent Host harnesses. Managed-settings or harness-availability changes are suspected, including reports involving permissions.disableBypassPermissionsMode, but the triggering event and regression commit are not yet confirmed.

Code finding

There is a plausible persistence defect in the shared composer:

1. Mode-list changes run validateCurrentChatMode() and then _restorePersistedCustomModeIfAvailable().
2. Validation applies automatic Agent/Ask fallbacks through setChatMode() with its default storeSelection: true.
3. setChatMode2() serializes that fallback into the session input state.
4. Custom-mode restoration then reads the potentially overwritten state.

This can erase a preferred mode during temporary mode unavailability. However, it does not by itself explain an Ask transition: with chat.agent.enabled=true, a missing custom mode normally falls back to Agent. permissions.disableBypassPermissionsMode restricts auto-approval and does not directly disable Agent mode.

Expected

Temporary provider, harness, or mode unavailability should not permanently replace the user's selected mode. Restoration must also respect current policy and any explicit user mode change made while the preferred mode is unavailable.

History / attribution

• fd9cf8e3dd1 (chat: refactor input state to be central #278683) introduced the relevant session-input mode persistence mechanism.
• 61915ccbab01b (Show disabled Agent mode with policy indicator instead of hiding it #278650) added the Agent-disabled-to-Ask validation branch.
• 8fa554d6e0030 (feat(chat): enhance model selection logic and session handling #324843) added late custom-mode restoration after validation.
• fa5d013e93f (policy: disable 3P harnesses under managed settings #331715) changes Claude/Codex availability under managed settings and may expose the persistence behavior for those sessions.
• There is not enough evidence to identify policy: disable 3P harnesses under managed settings #331715 or Fix managed sandbox settings and session bypass controls #338172 as the regression for the reported cross-harness Ask reset.

Investigation needed

Capture the event sequence when the reset occurs:

• session type / harness;
• current UI mode and persisted input-state mode;
• effective chat.agent.enabled value and policy source;
• mode list before and after the reset;
• managed-settings and provider/harness availability changes.

Add sequence-based coverage for:

• custom mode disappearance and reappearance;
• built-in Agent disable and re-enable;
• persisted custom mode while Agent mode becomes policy-disabled;
• explicit user selection while a preferred mode is unavailable;
• unrelated input-state synchronization during the availability gap.

A simple storeSelection: false change in validation is insufficient: custom-mode restoration can immediately undo Agent disablement, built-in Agent is not restored after re-enable, and later input-state synchronization can still serialize the fallback mode.