René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Simulator defaults refresh does not reconcile when both simulatorId and simulatorName are set","articleBody":"## Context\n\n`simulatorName` is the stable, canonical identity for a simulator selection. `simulatorId` in `.xcodebuildmcp/config.yaml` is allowed as a cached/convenience value (useful for sole developers), but it is expected to be reconciled in memory on each contributor's machine so a committed UUID does not break tools when cloned to a different environment. This reconciliation intentionally never writes back to disk — we don't want config churn from contributors each having different local simulator UUIDs.\n\n## Bug\n\n`refreshSimulatorDefaults` in `src/utils/simulator-defaults-refresh.ts` only reconciles when exactly one of `simulatorId` / `simulatorName` is present:\n\n```ts\nif (!simulatorId \u0026\u0026 simulatorName) {\n  // name -\u003e id, in-memory\n}\nif (!simulatorName \u0026\u0026 simulatorId) {\n  // id -\u003e name, in-memory\n}\n```\n\nWhen **both** are set in the project config (the common and recommended shape, e.g. `example_projects/iOS_Calculator/.xcodebuildmcp/config.yaml`), neither branch fires. The stale committed `simulatorId` is kept in the session store as-is, and downstream `resolveSimulatorIdOrName` (`src/utils/simulator-resolver.ts:92-113`) short-circuits on it without validating against `simctl`, so the stale UUID is passed directly to `xcrun simctl` on any machine that doesn't happen to have that UUID.\n\n## Expected behaviour\n\nAt MCP runtime bootstrap (`hydrateSessionDefaultsForMcp` in `src/runtime/bootstrap-runtime.ts`), when both `simulatorId` and `simulatorName` are present:\n\n1. Resolve `simulatorName` -\u003e id via `resolveSimulatorNameToId`.\n2. If the resolved id equals the committed `simulatorId`, do nothing.\n3. If it differs, patch `simulatorId` (and recompute `simulatorPlatform` as the existing branches do) in the session store via `sessionStore.setDefaultsIfRevisionForProfile` with `persist: false`.\n\nThe `persist: false` is critical — this is an in-memory override per contributor, not a write-back.\n\n## Proposed fix\n\nExtend `refreshSimulatorDefaults` with a third branch that handles the both-set case, reusing `resolveSimulatorNameToId`. Add unit tests in `src/utils/__tests__/` covering:\n\n- Both set, name resolves to the same id — no patch applied.\n- Both set, name resolves to a different id — in-memory patch updates `simulatorId`; no call to `persistSessionDefaultsPatch`.\n- Both set, `simctl` lookup fails — existing `simulatorId` retained, warning logged.\n\n## Surfaced by\n\nCursor Bugbot review on #349 (https://github.com/getsentry/XcodeBuildMCP/pull/349#discussion_r3139578705), though the bot's framing (committed UUID is a regression) differs from the actual root cause captured here.","author":{"url":"https://github.com/cameroncooke","@type":"Person","name":"cameroncooke"},"datePublished":"2026-04-24T21:24:33.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/357/XcodeBuildMCP/issues/357"}