Proposal: Let Desktop inherit existing CLI configuration and provide guided plugin migration

[shaoqing404]

When I installed DeepSeek Harness Desktop, I found a conflict with my existing CLI configuration. The new state effectively masked the old setup. The settings were recoverable, but I had to find and restore them manually. This should not happen at the product or engineering level.

Other users have reported related migration problems in #7453 and #7534. These problems do appear as products evolve. Once exposed, the question is how quickly we can provide a solution that protects existing user state. If the wider Harness ecosystem will support Desktop, CLI, OAuth, SSO, and more authentication options, configuration ownership and migration deserve careful treatment.

Then I wondered whether the RMB 6 credit offered with the new app was a little surprise from the product team: payment for users to fix their own bugs. For a moment, I thought it was my bug-fixing wage.

OK, back to the proposal.

1. Detect and inherit existing CLI configuration on first launch. Discover the existing Harness home and profiles. Automatically carry over compatible settings, including provider definitions, model options, and defaults. Ask the user to choose only when a conflict needs a decision. Preserve settings the app cannot yet understand.

2. Make DeepSeek account sign-in additive. After login, add the account-backed models alongside existing API providers. Keep the user’s current default unless they choose to change it. Settings should provide a clear place to manage both “DeepSeek Account” and “Local APIs.” The login callback should save the account authorization without reinitializing unrelated provider or model settings.

3. Make migration recoverable. Preserve a backup, validate the destination, and commit the changes atomically. If migration fails or only partially succeeds, show which entries failed, retain the original, and provide a retry or restore action. An empty destination should never count as a successful migration.

Plugin migration is also worth discussing—assuming Desktop eventually becomes the main maintained entry point, rather than treating that as an announced roadmap.

Could the app discover plugins previously built or installed through the CLI, reinstall them for its own runtime, and carry over their configuration and enabled state? Compatibility checks should cover plugin versions and required services. Unsupported plugins should remain visible with an actionable explanation.

For user-written plugins, Settings could offer a small “Import or sync CLI plugins” entry. Clicking it would start a dedicated Harness session, guided by a migration skill or plugin. Harness could inspect the selected plugins, adapt their code where necessary, and explain the changes and any unresolved incompatibilities. The app would manage backups, validation, and rollback; credentials would stay in the credential store.

That would give users a natural path from CLI to Desktop, including the capabilities they have already built.

This big whale has caused me plenty of trouble, but I’m still happy to help train it.