Supported browser-session revocation procedure for Harness 0.2.1-rc.2

[ridderek]

I'm running DeepSeek Harness 0.2.1-rc.2 on Windows 11 using the Web client.

I'm preparing a security-sensitive local integration and need to revoke a previously exposed Web launch token and any browser-session cookies derived from it.

The published Connection documentation indicates:

• Restarting Harness rotates the process launch token.
• Browser-session cookies remain valid across ordinary restarts.
• Global revocation requires deletion of the client-connection/browser-session credential record followed by a restart.

I found the credential service's deleteRecord API, but couldn't identify a supported CLI command or administrative UI action.

What is the recommended operator procedure to globally revoke existing browser sessions on this version?

Ideally, I'm looking for a supported approach that preserves unrelated model credentials, sessions, profiles, and workspace configuration.

I'd also appreciate guidance on verifying that previously issued browser cookies can no longer authenticate.

Thank you!

[Muguett-DBY]

For rc.2 with the default local credential provider, the documented manual route is:

1. Fully stop all Harness processes using that home.
2. Make a private backup of .credentials.yaml. The default is %USERPROFILE%\.dsh\.credentials.yaml; use the actual location if you've set DSH_HOME or the provider's path.
3. Under records, remove only the client-connection/browser-session key and its entire value. Keep version, refs, and the other records. If it was the last record, leave records: {}.
4. Start Harness again and use the newly generated launch URL to sign back in.

The rc.2 local-provider documentation explicitly supports direct file edits. Connection keeps the signing secret in memory, so the provider reloading the file alone doesn't revoke an already-running Connection. The Connection documentation describes the activation/restart requirement.

To verify, request the clean application URL with only the old cookie, at the same scheme, hostname and port, with no ?token=. Expect 401. A fresh launch URL should return 303, and its newly issued cookie should then authenticate with 200. Keeping the authority unchanged matters; changing the hostname or port would invalidate the cookie even without revocation.

I checked the rc.2 auth module with the real local provider in an isolated Windows fixture: ordinary restart kept the old cookie valid; deleting that one record and restarting rejected it. The unrelated reference and credential record stayed unchanged.