workspace: tool routing (precedence/engine-probes) ignores the IDE extension's pin, so a pinned session can name one workspace and route to another

[sahrizvi]

Problem

#1320 makes the IDE extension's pin (ALTIMATE_PINNED_WORKSPACE_{ID,NAME,ROOT}) outrank the project's stored binding inside resolveBindingOutcome, so skill-sync, memory-sync and (since #1330) the identity section all follow the pinned workspace. Warehouse tool routing does not. precedence.ts currentBinding() (~line 441) and engine-probes.ts resolveBinding() (~line 42) read the on-disk binding cache directly through readLocalBindingScopedStrict and never consult the pin; neither file changed in #1320, and the pin is deliberately never persisted, so routing cannot see it.

Observable in a pinned serve session (found in the v0.12.1 release review by two reviewers independently):

• Fresh pin, no prior local link (pin → 42): identity says "This project is linked to Altimate Workspace id 42"; derive() sees no binding → unbound → the routing section is silent and every warehouse call goes to the local tools. The pin changes what is remembered and which skills load, not what executes.
• Returning user, local cache still names workspace 7 (pin → 42): identity names 42, the routing section names 7 ("Altimate workspace "…" (id 7) serves the warehouse tools named below"), or — if the live engine is attributed to 42 — the attribution check fails and routing settles unattributed. Two different datamate ids in one prompt, with nothing telling the model which governs execution.

Routing behaviour is unchanged from v0.12.0 (the pin never affected it), so this is not a regression and nothing executes against a workspace the project was not already linked to — but it defeats the stated purpose of the pin for warehouse queries, and #1330 now makes the contradiction visible to the model every turn. v0.12.1's identity copy states the limitation for pinned sessions ("warehouse tool routing follows the project's own link, not the pin") as a stop-gap.

Expected

currentBinding() in precedence.ts and resolveBinding() in engine-probes.ts honour a valid pin the same way resolveBindingOutcome does (pin outranks the cached binding and auto-adoption; invalid/non-member pin fails closed to unbound routing), so identity, routing, skills and memory agree on one workspace within a turn. The redirect-guard and attribution tests in precedence.test.ts need the pinned case added.

Related: #1335 (workspace name in the system prompt), and the #1320 known gaps (no backfill on pin, no purge-before-fetch in skill-sync).

🤖 Generated with Claude Code

https://claude.ai/code/session_012Q51zFUmPg1WwtS5CrGJE6

[anandgupta42]

Reproduced on 0.12.1 while testing #1320 end to end (tenant anandtest1).

Setup: project pin-1 bound to workspace 5 (pin-1); a second workspace 7 (pin-2) holding a published skill magic-pin-answer. Headless turn in pin-1 with ALTIMATE_CODE_SERVE=1 ALTIMATE_PINNED_WORKSPACE_ID=7 ALTIMATE_PINNED_WORKSPACE_NAME=pin-2 ALTIMATE_PINNED_WORKSPACE_ROOT=<pin-1 path> OPENCODE_PRINT_LOGS=1.

• Pin honoured for skills and memory: resolved the workspace pinned by the IDE extension datamateId=7 datamateName=pin-2, workspace skills synced datamateId=7 skills=1; the pin-2 skill fired on a plain question.
• Identity section follows the pin: the model answered "This project is linked to Altimate Workspace pin-2 (ID 7)."
• Routing does not: every turn logs workspace-precedence … bound=5, i.e. tool routing still keys off the project's own binding while identity and skills say workspace 7.

So a pinned session names one workspace and routes to another, exactly as this issue describes. The fail-closed path (ALTIMATE_PINNED_WORKSPACE_ID=999999) behaves as #1320 states: pinned workspace is not visible to this account, no skills, no memory, and the user is told to check the IDE selection or run altimate-code link.