An Automation should behave more like an appointment than a cursor. In different-ai/openwork, the public workspace-pinning change says the desktop runner and cloud executor had been resolving a job against whichever workspace happened to be active at run time. Switch projects after scheduling the work, and the job could follow the switch without announcing that it had changed homes.
The different-ai/openwork repair is deliberately unglamorous: an Automation revision may now carry a workspaceId from creation through execution. The desktop runner looks for that exact workspace; if it is absent locally, it reports an unavailable runtime instead of choosing the active workspace. Its new regression witnesses make the distinction explicit: a pin beats the active workspace, while an older unpinned assignment keeps the old fallback.
A job now has a place
The most revealing detail is where the pin comes from. In the proposal surface, OpenWork takes the workspace from the pane that renders the proposal and deliberately ignores a workspace ID supplied by the agent. That gives the person looking at the proposal a visible execution context, then carries it into the job. It is a modest rule with a large operational payoff: the target of autonomous work becomes a recorded fact rather than a side effect of someone’s most recent navigation.
The old exception still matters
This is not a claim that every OpenWork automation is now immovable. The field is optional, and the commit preserves active-workspace selection for legacy assignments; the public receipts are main-branch code and tests, not release or production evidence. But the audit question is suddenly plain: does a scheduled agent have an explicit target that survives a person changing tabs or projects? The next useful signal is migration guidance—or an operator view—that can show which older jobs still answer “where should I run?” with “wherever the user clicked last.”