v0.31.7

Security

Check your integrations before upgrading if you use API keys from more than one workspace. After this release, a key made in a workspace other than the Default Workspace works inside that workspace only. A script that used such a key on another workspace's harnesses or tasks, or to create keys for other workspaces, now gets "not found" or "forbidden". Use a key of that workspace, a key made in the Default Workspace, or an organization key. Keys made in the Default Workspace, which is what most installs have, behave as before.

• A workspace's API key could act on other workspaces of the same organization. The API Keys page says a key is for the selected workspace, and listing held to that. But a workspace's key that knew another workspace's id could read, rename and delete its harnesses; read its tasks, files and answers and publish a share link for them; cancel and delete its tasks; revoke its keys; and create a key for the whole organization under any name. A workspace's key now reaches that workspace and nothing else.

  Who is held to one workspace: an API key made in a workspace other than the Default Workspace. Not held: a person signed in to the console, an organization key, and a key made in the Default Workspace.

New

• Organization keys, chosen on purpose. When you create a key outside the Default Workspace, the dialog now asks its reach: that workspace only, or an organization key that reaches every workspace. In the Default Workspace the dialog says plainly that a key made there reaches every workspace.

Checked

On 0.31.6 and on this release's candidate, with keys for two workspaces, an organization key and a Default Workspace key:

With workspace B's key, against workspace A	0.31.6	0.31.7
Read A's harness, tasks, files and answers	allowed	not found
Rename A's harness, cancel A's task, publish a share link	allowed	not found
Revoke A's key	allowed, and A's key stopped working	not found
Continue A's conversation	started	not found
List the organization's harnesses and keys	everything	its own workspace's
Create a key for the whole organization	allowed	it gets a key for its own workspace
Create a key for workspace A, or a new workspace	allowed	forbidden

Still works: a workspace's own key, an organization key, a Default Workspace key and a person in the console all reach every workspace as before; a Default Workspace key creates and revokes a workspace's key. In the console, every page loads, a harness created there runs a task, and the new Reach choice was checked at four screen widths. Claude Code tasks complete and all plugin checks pass on Claude Code, Codex and Pi.

Reported privately by @jankesec (GHSA-9pjr-97x3-c4wv), by Omer Bar-Ness, MergeSafe (https://mergesafe.ai) (GHSA-cgf4-38c9-39vr), and by @Tike00, whose report also covers an issue fixed in the next release. Thank you.

docker run -d -p 3000:3000 -v hr-data:/data harnessrouter/harnessrouter:0.31.7

Full Changelog: v0.31.6...v0.31.7