[Bug]: renaming a provider kills in-flight work in every thread using it

[Simoki0]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

Not sure

Steps to reproduce

1. Have one or more threads actively running against provider X.
2. Go into settings and delete provider X, or edit its name.
3. Return to the threads.

Expected behavior

running threads finish their current turn; the provider record is looked up by a stable ID, so a rename is cosmetic. At worst, a warning before deleting a provider that has active threads.

Actual behavior

all work in every thread on that provider stops.

Impact

Blocks work completely

Version or commit

No response

Environment

No response

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[juliusmarminge]

Triage

Confirmed against current main. This is a real bug, not a duplicate of #5750.

Threads already bind to a stable ProviderInstanceId. The Settings “Display name” field is supposed to be cosmetic. In practice, any change to the ProviderInstanceConfig envelope — including displayName or accentColor — goes through ProviderInstanceRegistry.reconcile, which treats the instance as replaced, closes its scope, and tears down every live adapter session on that instance. Delete is the same path with no confirmation.

That matches “rename or delete provider X → all in-flight work on X stops.”

#5750 is the other direction: a provider disappearing during update/restart can leave turns stuck Working. Here the server intentionally rebuilds the instance. Claude’s adapter finalizer also stops sessions without emitting session.exited, so some threads may look stuck after a rename — related fallout, not the same root cause.

No open PR found for this.

Suggested fix

1. Do not rebuild/tear down an instance for presentation-only edits (displayName, accentColor).
2. Before delete (and other rebuilds that must kill sessions), warn if that instance has active threads — same idea as the Antigravity disconnect copy.
3. Add a registry test that a display-name-only reconcile keeps the existing live instance.

Leaving this open as an accepted bug.