contextTier setting (e.g. long_context) is not restored from settings.json on startup

[astegmaier]

Describe the bug

When a model with a long-context tier (e.g., claude-opus-4.7-1m-internal with the 1M context tier) is selected via /model, the contextTier value is correctly persisted to ~/.copilot/settings.json as "contextTier": "long_context".

However, on subsequent CLI launches, the persisted contextTier is not restored. The model field is loaded correctly, but the session silently falls back to the default (smaller) context tier. The user must re-run /model and re-select the long-context tier every single session for it to take effect.

This defeats the persistence that the setting clearly intends to provide, and forces anyone relying on long-context models to remember a manual step every time they start the CLI.

Affected version

Copilot CLI v1.0.55-7 (macOS, darwin-arm64)

Steps to reproduce the behavior

1. Launch the CLI and run /model. Select a model with a long-context tier (e.g., claude-opus-4.7-1m-internal + 1M context).
2. Confirm the CLI shows the tier indicator (e.g., "(1M context)") and that ~/.copilot/settings.json now contains both:

   {
     "model": "claude-opus-4.7-1m-internal",
     "contextTier": "long_context"
   }

3. Run /context and confirm the context window shows the long-context size (~1M tokens).
4. Exit the CLI.
5. Open a fresh terminal and launch a new session (copilot).
6. Run /context again.

Expected behavior

The new session should restore both model and contextTier from ~/.copilot/settings.json. /context in the new session should show the long-context size (~1M tokens), matching what was shown before exit.

Actual: The model is restored correctly, but the tier reverts to the default. /context shows the smaller window:

○ ○ ○ ○ ○ ○ ○ ○ ○ ○   claude-opus-4.7-1m-internal · 53k/200k tokens (26%)

The only way to get the long-context tier back is to re-run /model and re-select it, every session.

Additional context

Root cause (from inspection of v1.0.55-7 app.js)

On session startup, the model is restored via:

this.session.setSelectedModel(l.model, c)   // c = defaultReasoningEffort

Only model and reasoningEffort are passed. The contextTier field is loaded from settings elsewhere in the code (no.load(...)), but it is never threaded into this initial setSelectedModel call.

Inside applyModelChange, this.contextTier is only overwritten when the incoming argument is defined:

r?.contextTier !== void 0 && (this.contextTier = r.contextTier ?? void 0)

So when the startup call omits it, this.contextTier stays undefined and the session falls back to the default tier — regardless of what's on disk.

By contrast, when /model is used interactively, the picker explicitly passes contextTier to setSelectedModel(ne, nn, Ai, void 0, at) and to applyModelChange({ ..., contextTier: s }). That is why the tier works mid-session but not on launch.

Suggested fix

At the startup call site (where l = await no.load(settings) is consumed), pass l.contextTier as the 5th argument to setSelectedModel, mirroring what the /model flow already does.

Workarounds attempted (none viable)

• Manually editing ~/.copilot/settings.json to set "contextTier": "long_context" — value persists on disk but is ignored at startup.
• Environment variable override — none exists. The binary exposes COPILOT_MODEL, COPILOT_MODEL_FAMILY, COPILOT_AGENT_MODEL, and a few provider overrides, but nothing for contextTier.

Impact

Anyone relying on long-context model variants (e.g., 1M context) has to remember to re-select the tier every session. This is especially painful for long sessions or for users who frequently start new sessions across multiple terminals.