[Bug]: Simulator tools silently ignore explicit arguments when session defaults are set

[chrisamber]

Bug Description

The simulator tools (build_sim, build_run_sim, test_sim) silently discard explicitly-passed arguments when session defaults are configured. The provided value is not merged, not warned about, and not echoed — the session default (or an empty value) is used instead.

This is easy to miss because the response's request object reports the effective values, so the discard is only visible if you compare it against what you sent.

Note this is distinct from #443: there the argument is absent and a hardcoded Debug is injected. Here the argument is present and is dropped.

Steps to Reproduce

Session defaults in the active profile (ios) at the time of each call:

scheme:        SongscriptiOS
configuration: Debug
simulatorId:   A3B1E4B2-…  (iPad Pro 13-inch (M5))
simulatorName: iPad Pro 13-inch (M5)

1. simulatorId is ignored — passed a different, valid, booted simulator:

// call
{ "simulatorId": "B2EAD74A-…" }        // iPad Pro 13-inch (M5) (16GB)
// response.data.request
{ "simulatorId": "A3B1E4B2-…" }        // session default used instead

2. simulatorName is ignored:

// call
{ "simulatorName": "iPhone 17e" }
// response.data.request
{ "simulatorId": "A3B1E4B2-…" }        // session default used instead

3. configuration is ignored:

// call
{ "configuration": "Release" }
// response.data.request
{ "configuration": "Debug" }           // session default used instead

4. test_sim drops onlyTesting — note this key has no session default, and it still gets emptied:

// call
{ "onlyTesting": ["SongscriptiOSTests/ChordProExportServiceTests"] }
// response.data.request
{ "onlyTesting": [], "skipTesting": [] }

The run then executed the full suite (63 tests) rather than the one requested.

Not universal

build_macos does honour explicit arguments. With the same ios profile active (scheme: SongscriptiOS), calling build_macos with scheme: "Songscript" used the passed scheme, not the profile's. So the defect appears specific to the simulator tools rather than to argument plumbing in general.

Expected Behaviour

An explicitly-passed argument should take precedence over the session default for that call. Session defaults are meant to remove repetition, not to pin a value that can no longer be overridden.

If overriding is deliberately unsupported for some fields, the call should fail loudly rather than silently substituting a different value.

Impact

Beyond the obvious "can't target a different simulator for one call", the silent substitution produces a genuinely misleading failure when a stored default goes stale.

If the default simulatorId points at a simulator that has since been deleted, every build_sim fails with:

Unable to find a device matching the provided destination specifier:
    { platform:iOS Simulator, id:A7C309F6-… }

…naming the stale UDID — even when the call explicitly passed a valid, booted one. The error reads as though the caller supplied the bad identifier. The only fix is to notice the session default is stale and rewrite it with session_set_defaults; passing a good simulatorId per-call has no effect. This cost me a while to diagnose, since the obvious remedy (pass an explicit simulator) is exactly the thing that doesn't work.

Environment

• XcodeBuildMCP 2.5.2 (Homebrew, stdio transport)
• XCODEBUILDMCP_ENABLED_WORKFLOWS=simulator,macos,debugging,project-discovery
• macOS Darwin 27.0.0
• Xcode 27.0 (27A5194q)

Possibly related

• [Bug]: Build tools inject hardcoded -configuration Debug, overriding the scheme's configuration #443 — hardcoded -configuration Debug when no configuration is given (the absent-argument counterpart of item 3)
• debug_attach_sim: session-defaults bundleId collides with explicit pid, validation blocks attach #410 — session-defaults bundleId colliding with an explicit pid
• Simulator defaults refresh does not reconcile when both simulatorId and simulatorName are set #357 — simulator defaults not reconciling when both simulatorId and simulatorName are set