Nothing to try yetTier: how much it should matter to you
4Useful: my rating, 1 to 5
4Signal: worth watching, 1 to 5
Workspace TrustArea: what it touches
Internal ChangesKind: in v2.1.265,
What probably matters to youSection of the release
What
The SDK/CLI initialize request now accepts an optional workspaceTrust object ({accepted, directory}) so a host application (for example, Claude Desktop's Code tab over SSH/WSL) can attest that it already showed its own trust dialog for the working directory, instead of the CLI needing to show its own.
A new handler validates that the directory is an absolute path, resolves to the same trust key as the session's working directory, and isn't a screened/untrusted network path, then records the directory as trusted the same way the interactive terminal dialog does, and re-applies project settings afterward. The outcome is reported via telemetry.
The initialize response gains a workspace_trust_recorded boolean (marked internal) reporting whether the attestation was actually persisted as trust — it can be false for reasons like an obfuscated/untrusted path, a wrong key, a write failure, or a home-directory session-only trust.
The same workspace_trust_recorded field is included in the system-init/hello JSON payload sent out, alongside existing fields like current_permission_mode and hooks_applied.
Why
This lets a host that already handles its own trust UI (like Claude Desktop) skip showing a redundant trust prompt inside the CLI, while still letting the CLI confirm and record whether that trust was actually saved.
