Repository navigation
Layout sunset hard-codes the new layout with no override for desktop users #49005
Description
Activity
This issue might be a duplicate of existing issues. Please check:
- [FEATURE] : keep legacy layout option #37012: [FEATURE]: keep legacy layout option — same core request to preserve the legacy layout
- [FEATURE]: Restore the legacy UI with the persistent left sidebar as an option #48882: [FEATURE]: Restore the legacy UI with the persistent left sidebar as an option — same root cause and feature request
- [FEATURE]New users can't switch back from the new layout — no layout toggle available #39835: [FEATURE] New users can't switch back from the new layout — same sunset/toggle behavior
- Original Layout Forcibly Replaced with a Single-Conversation Context Interface #48888: Original Layout Forcibly Replaced with a Single-Conversation Context Interface — same complaint about the forced new layout
Since this issue itself lists several of these as related, it may be more productive to consolidate the discussion in one of the earlier threads rather than opening a new one. The maintainers can decide whether to keep this open or close as a duplicate.
I've been affected by this since the sunset date. Two specific pain points:
- Switching sessions requires navigating to the home page first - in the old layout, the project sidebar with sessions was always visible, so switching was one click. Now it takes an extra step every time.
- Tab titles don't show project name or path - I work across multiple projects and can't distinguish which project a tab belongs to without hovering. Issue [FEATURE]: Allow the project and session sidebar to be used alongside session tabs #37273 captures this.
The asar patching workaround breaks on every update. A simple env var like OPENCODE_USE_LEGACY_LAYOUT=1 would solve this immediately. +1
Built an unofficial Windows build that restores the old layout while this
gets sorted upstream — keeps the legacy sidebar available past the sunset
date instead of forcing the new layout:
https://github.com/kuznecov-anatoliy/opencode-old-interfaceNot affiliated with the team, just a stopgap. Happy to also open this as a
PR against dev if useful, since the root cause is already pinned down here.You nailed the mechanism - oldInterfaceSunset really does hard-code the new layout with no escape hatch. Until an official override lands, this is a working escape hatch (Windows Desktop):
https://github.com/davidlopezsalvador/opencode-legacy-patch
How it works: a same-length patch inside
app.asarmovesoldInterfaceSunsetto 2099, soresolveNewLayoutDesigns(retired, ...)stops hard-coding the new layout, andapp-update.ymlis neutralized so the auto-updater cannot silently wipe the patch.- Tested on 1.18.34 -> 1.18.35 (Electron 42, Windows); applies with the app open in ~2 minutes; one-command rollback (
-Mode restore). - Fail-safe: the script searches the literal dynamically and aborts unless it finds exactly 1 occurrence.
- Caveats: Windows desktop only; updates frozen until you
restore -> update -> patch(script included); unofficial, use at your own risk.
I maintain the repo, feedback welcome. This is only a stopgap until a permanent official toggle ships.
- Tested on 1.18.34 -> 1.18.35 (Electron 42, Windows); applies with the app open in ~2 minutes; one-command rollback (
Layout sunset hard-codes the new layout with no escape hatch for existing desktop users
When the
oldInterfaceSunsetdate passes, desktop users who want to keep the original ("legacy") layout are stuck with the new layout and receive a dismissible notice instead of a toggle. This is a product decision, but there is currently no opt-out or override, and the related threads below have been open for months without a response.Related (all appear to be the same root cause):
Root cause
All interactivity is gated on
oldInterfaceSunsetinpackages/app/src/context/settings.tsx:oldInterfaceSunset = new Date(2026, 8, 14)(line 63) — onceDate.now() >= this, the hub retires the old interface.resolveNewLayoutDesigns(retired, preference, fallback)(line 129) —if (retired) return trueignores any saved user preference.layoutTransitionState(line 116) —available: scheduled && eligible && !retiredhides the Settings toggle entirely after the sunset.setNewLayoutDesigns(line 432) —const next = oldInterfaceRetired() ? true : valueblocks switching back after the sunset.newLayoutDesigns = trueonce retired.There is no environment variable, config key, or CLI flag that overrides any of this.
Verified local workaround
For desktop builds (Electron asar), replacing the following byte-for-byte keeps the toggle available and lets users stay on the old layout:
if (layoutUpgrade()) return true→ an emptyif (layoutUpgrade()) {}block (removes the force-intro of the new layout for upgraders).new Date(2026, 8, 14)→ a far-future date (e.g.new Date(2099, 0, 14)) sooldInterfaceRetired()stays false and the Settings toggle remains available.Caveat: in the minified renderer bundle (strict-mode ES module), the replacement must avoid a leading-zero numeric literal (
new Date(2099, 0, 01)is an octal literal and throwsSyntaxError: Octal literals are not allowed in strict mode, which crashes the whole renderer on startup).Feature request
Please provide a supported, durable path for existing users to stay on the original layout, for example:
OPENCODE_USE_LEGACY_LAYOUT=1) that keeps the toggle available regardless of the sunset date, oroldInterfaceRetired() ? true : valuegate and the force-set effect), which is what the workaround above effectively does.If the sunset must stay, a reprieve (like earlier postponements) plus a documented override would still let long-time users keep their preferred interface.