Session-scoped settings.yaml provider overrides silently ignored on `amplifier resume` (amplifier-app-cli)

[danshapiro]

Summary

Bug: amplifier resume <session_id> silently ignores session-scoped settings.yaml provider overrides, making them non-functional for workload recovery.

Impact: Users cannot use session-scoped config overrides (e.g., enable_response_chaining: false) to recover from issues like #321 (response-chaining context overflow). The workaround suggested in #321 does not work due to this defect.

Root cause: Resume code path builds an un-scoped AppSettings() instead of AppSettings().with_session(session_id, project_slug), so session-scoped settings files are never loaded.

---

Verified Evidence

Location of defect: amplifier-app-cli

This defect is in the CLI reference implementation, not amplifier-core. However, since microsoft/amplifier-app-cli has issues disabled and is marked as a reference implementation not accepting external contributions, this issue is filed in amplifier-core for visibility and tracking.

Code evidence

File: amplifier-app-cli/amplifier_app_cli/commands/session.py

1. Line 131 — Unscoped AppSettings() built at resume choke point:

   app_settings = AppSettings()  # WRONG — should use .with_session()

   This occurs in _prepare_resume_context(), which is the single choke point all four resume code paths funnel through (interactive_resume, spawn_session_from_saved, etc.).

2. Line 139 — project_slug computed AFTER settings are built:

   project_slug = ...  # computed here, AFTER line 131

   This means the fix requires reordering: compute project_slug first, then call AppSettings().with_session(session_id, project_slug).

Why session-scoped settings are silently skipped

File: amplifier-app-cli/amplifier_app_cli/lib/settings.py

1. Line 112-115 — .with_session() correctly rebuilds scoped paths:

   def with_session(self, session_id, project_slug):
       return AppSettings(paths=self.paths.with_session(session_id, project_slug))

2. Line 357 — .get_provider_overrides() reads from self.paths.session_settings:
   On a plain AppSettings(), self.paths is built without session context, so self.paths.session_settings is None.

3. Line 376-387 — .get_merged_settings() silently fails on missing paths:

   except: pass  # Silent failure when self.paths.session_settings is None

   No error is logged; the session-scoped override is simply omitted.

Inconsistent pattern found

File: amplifier-app-cli/amplifier_app_cli/lib/settings.py, lines 1031-1066

The codebase already has the correct pattern for tool overrides:

def get_tool_overrides(self, session_id=..., project_slug=...):
    # CORRECTLY uses session_id and project_slug to construct scoped path

This proves the pattern works but was only applied to tool overrides, not to provider overrides in the resume path.

Impact on session 507f3164-6b1e-48ff-a8ce-766e5cdbde76

• User attempted to recover from [provider-openai] Response chaining sends previous_response_id AND full conversation history, double-counting server-side context #321 (response-chaining overflow) using session-scoped settings.yaml with enable_response_chaining: false
• Offline check using .with_session() directly confirmed the override would resolve to False
• Live amplifier resume immediately failed with identical error because the setting was never loaded
• This proved the override mechanism itself (file creation, storage path) works, but the resume code path doesn't read it

---

Suggested Fix

In amplifier-app-cli/amplifier_app_cli/commands/session.py, _prepare_resume_context():

1. Reorder to compute project_slug before building app_settings
2. Change line 131 from:

   app_settings = AppSettings()

   to:

   app_settings = AppSettings().with_session(session_id, project_slug)

This closes the gap where only get_tool_overrides() was session-aware, but get_provider_overrides() was not.

---

Testing

Add a regression test asserting that:

1. A session with a session-scoped settings.yaml override (e.g., enable_response_chaining: false) is created
2. amplifier resume <session_id> loads the override (verify via session:config diagnostic event or CLI output)
3. The override value flows to the actual mounted provider instance
4. Verify this works for multiple provider override types (not just enable_response_chaining)

---

Related

• [provider-openai] Response chaining sends previous_response_id AND full conversation history, double-counting server-side context #321 — Response chaining context overflow; suggests session-scoped override as workaround, but that workaround is currently non-functional due to this defect
• feat: resume-time provider-mismatch guard + session repair/diagnose commands amplifier-app-cli#233 — Provider mismatch guard and session repair (related infrastructure work)

---

Notes for maintainers

• The defect is low-severity operationally (requires explicit session-scoped settings.yaml to trigger) but high-severity for recovery workflows (blocks the [provider-openai] Response chaining sends previous_response_id AND full conversation history, double-counting server-side context #321 workaround)
• This is a reference implementation issue, not a core Amplifier kernel issue
• microsoft/amplifier-app-cli has issues disabled; this issue tracks the defect for visibility

[danshapiro]

Runtime resolution evidence: override discarded, runtime fell back to auto

Adding the concrete observed runtime value that pins this defect down (the report above establishes the code path; this records what the live resume actually resolved to).

For session 507f3164-... (provider-openai / gpt-5.6-sol), with a session-scoped settings.yaml containing enable_response_chaining: false:

• Offline, session-aware resolution → False. Resolving via AppSettings().with_session(session_id, project_slug).get_provider_overrides() returned Python False (unquoted YAML boolean, correctly parsed — not the string 'false').
• Live amplifier resume runtime → auto. The running provider resolved enable_response_chaining to the global default auto, i.e. the session-scoped false was never applied. Chaining therefore stayed active and the request failed again with the identical context_length_exceeded.

The delta between the offline (False) and runtime (auto) resolution is the direct signature of the resume path building an unscoped AppSettings() (per commands/session.py:131 above) and silently discarding session scope — not a YAML/quoting error and not a user error.

Sanitized: opaque session id, config key/values, and provider-module file reference only — no local paths, transcript content, or secrets.