[slue]

Why

On multi-org agents, one workspace's worker run can lose another workspace's changes. The agent keeps a single changes cursor for all workspaces (on Ultron and Clawdia today). The run for workspace B reads the timestamp that A just wrote. Any comment in B older than that timestamp drops out of B's window. Christoph decided on GC edc45a5d: fix it in the CLI, not in the plugin.

https://groundcontrol.makerslab.ai/tasks/edc45a5d-654e-4c2b-86ba-b405927f05ea

What

• gc changes --cursor-file <path> now stores one cursor per workspace:
  • Format: {"<slot>": "<server cursor>"}.
  • The slot is the one gc listen already uses: the profile name, or key-<hash> for --token/GC_API_KEY. The key itself is never stored.
  • The naming now lives in a shared helper, workspaceSlot.
• The same file can be passed with every --profile. Runs neither read nor overwrite another workspace's entry.
• Compatibility:
  • A file with a bare timestamp (gc ≤ 0.2) is still read, and the next write upgrades it.
  • Another workspace then starts with the 1 h window, and stderr notes it.
• Breaking: scripts that cat the cursor file now get JSON. Nothing in the skills or the server guide does that.

Tests

New e2e cases:

• two workspaces in one file, neither reads or overwrites the other;
• a bare timestamp is read and upgraded;
• a broken JSON file fails with exit 1.

Existing cursor tests now read the workspace entry. go vet, go test ./... and validate-skills.sh are green.

Fleet follow-up

Plan 106 (switching from the plugin to the CLI): the spawn-cron prompts for multi-org tenants call gc changes --profile <p> --cursor-file memory/gc-changes.json. Needs a release (0.3.0) first.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KWPUqhbu3go1zaJ82YpXoz