API keys after uninstalling DeepSeek Harness: revoke

Uninstalling DeepSeek Harness removes local software, not the identity that software used, so an API key used by a dsh plugin can stay valid long after the directory is gone. Credentials are spread across configuration, environment variables, plugin data and logs, and only the provider console can truly revoke them. The cleanup order is inventory, revoke or rotate, remove residue, then decide what a reinstall should use.

Why DeepSeek Harness credentials outlive uninstall

Uninstall removes a program, not an identity, and the provider has no reason to notice that your machine changed.

A package manager deletes executables, cleans the registered install directory and removes some caches, and that is the whole scope of the operation. It never logs into a model provider and has no authority to disable a key on your behalf. It also does not touch user data that lives outside the package's own directories. That boundary comes from system permissions rather than from a missing feature, so no future uninstall script is likely to close it.

Configuration often stores a reference rather than the secret itself, while the real value arrives from an environment variable or a file that a plugin reads at runtime. Deleting the reference stops the local client from finding the key, but it does not change the key's status at the provider. A credential is tied to an account rather than to a machine, which is why another laptop, a scheduled script or a colleague can keep using the same key without noticing your uninstall.

Where a dsh plugin leaves credentials on disk

Build the location list before deleting anything, or the cleanup only removes the copy you happened to remember.

Related files usually sit in the user configuration directory, shell startup scripts, the plugin's own data directory and the logs or crash dumps. Different installation methods change the paths, but the categories remain stable enough to search for. A search for key prefixes across all four places is more reliable than trusting memory.

The distinction between a reference and the key itself decides whether a cleanup actually did anything. A reference points at a variable or a file, and removing it blocks reads, while only the provider can make the key itself invalid. The table above is a starting map rather than proof that a particular plugin follows it. Plugin directories are the most easily missed location, because a third-party plugin may store its own token under a name unrelated to the main program. Logs are the most dangerous, since request headers and crash dumps can contain the key in plain text and almost nobody revisits them.

Revoking and rotating DeepSeek Harness plugin keys

Revoke what will never be used again, rotate what must keep working, and do both at the provider rather than on disk.

Revocation makes an old key invalid, while rotation issues a new key, replaces the users and then retires the old one. Choosing the wrong operation either leaves a dead dependency in place or causes an avoidable outage, so the decision should follow the key's future rather than convenience. A revoke is irreversible in most consoles, so a key that might still serve a dependency should be rotated instead.

1. List every active key in the provider console and mark its purpose and machine.
2. Revoke keys that are definitely retired and record the time and operator.
3. Issue a new key for anything that must keep working, without disabling the old one yet.
4. Update configuration, environment variables and plugin references to the new key.
5. Send one minimal request with the new key and confirm the old key is rejected.

Verification requires an actual call, because a status page and a local edit can both look convincing without proving anything. If the provider shows a key status list, the old entry should be marked as revoked there as well. Scripts and scheduled jobs outside DeepSeek Harness may also depend on the key, so searching environment files and repositories before disabling the old value prevents a chain of unrelated failures.

Cleaning dsh plugin credential residue locally

Local cleanup prevents leakage; it does not replace revocation, because the remote key does not care what is left on your disk.

Configuration is the simplest location, since the key field can be deleted or changed to point at an empty reference. Environment variables must leave the shell profile, startup script and container definition together, because editing only the current session changes nothing after a new terminal opens. Plugin directories deserve a separate pass, especially for third-party DSH plugins that may keep tokens in their own storage, and the DSH Plugin Hub entry is the place to confirm whether a plugin stores anything independently.

Logs and crash dumps are easy to forget and expensive to ignore, because a failed request may have recorded the full header. Deleting them is acceptable when they have no remaining value, and redaction is better when they must be kept. A final search for the key prefix should include hidden directories, backup files and editor caches, since those are the places where copies tend to survive.

Rebuilding credentials before a DeepSeek Harness plugin reinstall

A reinstall is a chance to redistribute permissions, not a reason to restore the old key by habit.

Reuse is reasonable only when the old key was never revoked and never appeared in logs, backups or shared configuration. If there is any doubt about exposure, a new key costs one step and removes a long, unclear history. Splitting keys by purpose, such as chat, embedding and batch work, keeps the blast radius of a future leak small and calculable.

Store the new value in an environment variable or the system credential store, and keep a reference in configuration rather than plaintext in a repository. Record which machine and purpose each key serves, because that record is what makes the next cleanup possible. After the install, send one minimal request and recheck approval and workspace settings, since correct credentials with overly broad permissions remain a risk. The uninstall is most useful as a credential inventory, and a key that cannot justify its existence should not survive the reinstall.

Sources: deepseek-harness CLI README, DeepSeek Harness quickstart, npm @deepseek-ai/dsh.