Auto-upgrade during active session causes instability

[PaxGooroo]

Summary

OpenCode auto-upgrades itself (via curl script) without checking whether a session is active. When the upgrade coincides with other concurrent operations (e.g., a second instance), it can cause data loss and process death.

Steps to reproduce

1. Start a long OpenCode session
2. While the session is active, the auto-upgrade triggers (newer version detected)
3. The upgrade runs while the session is still writing to the SQLite database

Observed behavior

On 2026-07-13, an auto-upgrade from 1.17.19 to 1.17.20 occurred at 22:01:02 UTC, while:

• Session ses_0a327c364ffe9gjHZ1DNSUPYh3 (slug quick-meadow) was active on instance cec74255
• Session ses_0a2ee1f9bffe5LCXt0u0Rp8kn6 (slug silent-wizard) was active on instance 85243909

The auto-upgrade ran on instance b2b3534d:

2026-07-13T22:01:02.990Z  upgraded  run=b2b3534d  target=1.17.20

After the upgrade:

• Instance 8a5c1dc2 (spawned at the same second) died with 12 log lines
• Instance 85243909 survived until 22:01:21 then exited its loop
• Instance cec74255 last logged at 21:58:33 (already idle before the upgrade)

Log evidence

Same as #1 — the auto-upgrade was the triggering event that correlated with the crash of the second instance.

Expected behavior

Auto-upgrade should:

1. Check if any sessions are active before proceeding
2. Warn the user with a visible message: "A new version is available. Upgrade now or postpone?"
3. NOT force-kill or restart the process during an active session
4. Or at minimum, acquire an exclusive lock on the database before migrating

Additional context

The auto-upgrade mechanism uses curl | bash pattern which runs in-process. If the upgrade script modifies files while the process is running, it can lead to undefined behavior (e.g., hot-patching a binary that is currently executing).

Environment

• OS: Debian Linux
• OpenCode version: 1.17.18→1.17.20 (auto-upgraded)
• Upgrade method: curl (built-in auto-updater)

[PaxGooroo]

Update : doublon partiel identifie a posteriori.

Cette issue chevauche principalement :

• fix(cli): TUI crashes with unhandled transport defect during post-update service restart #36688 fix(cli): TUI crashes with unhandled transport defect during post-update service restart — decrit exactement le crash post-upgrade
• fix(cli): recover from concurrent service replacement during startup #35801 fix(cli): recover from concurrent service replacement during startup — le mecanisme de remplacement concurrent

Contexte : Debian 13 Trixie, KDE Plasma, 12 Go RAM. L'auto-upgrade 1.17.19 vers 1.17.20 s'est execute en plein milieu de 2 sessions actives, sans aucun avertissement utilisateur.

Je ferme en faveur des issues existantes.

[PaxGooroo]

Closed as duplicate — chevauche #36688 et #35801.