Web: no way to revert the new layout, and the new layout is missing workspaces/worktrees

[blancqua]

Summary

On OpenCode Web, upgrading past v1.17.19 auto-enables the new ("tabs on top") layout. Once enabled, there is no UI to switch back to the legacy layout, and the new layout does not implement workspaces (git worktrees) at all. Combined, this means a Web user who had workspaces enabled silently loses the feature with no in-app way to recover it.

Environment

• OpenCode Web (not desktop; I haven't tested desktop)
• Client: 1.18.2, Server: 1.18.3
• Reproduced against latest dev as of filing

Steps to reproduce

1. On OpenCode Web, be on a version ≤ 1.17.19 with the legacy layout and workspaces enabled for a git project.
2. Upgrade to 1.18.x. The new layout auto-enables (shouldEnableNewLayout flips newLayoutDesigns once you cross the 1.17.19 cutoff — packages/app/src/context/settings.tsx).
3. Open the sidebar / command palette and try to enable workspaces.
4. Open Settings → General and try to revert to the legacy layout.

Expected

• The "Enable workspaces" / "Toggle workspaces" controls remain available, or
• At minimum, a visible setting to revert to the legacy layout where workspaces still works.

Actual

• No workspaces UI in the new layout. The new layout (packages/app/src/pages/layout-new.tsx) is a shell (Titlebar + content) with no projects sidebar. The workspaces feature — the right-click "Enable workspaces" item (packages/app/src/pages/layout/sidebar-project.tsx) and the "Toggle workspaces" command palette entry — only exists in LegacyLayout (packages/app/src/pages/layout.tsx). layout-new.tsx has zero references to workspaces/worktree/sidebar. The server-side /experimental/worktree endpoint still works (returns []), so this is purely a client gap.
• No way to revert on Web. The "New layout" toggle in Settings → General only renders when layoutTransitionAvailable is true (packages/app/src/components/settings-v2/general.tsx, the <Show when={settings.general.layoutTransitionAvailable()}> block). That requires layoutTransitionEligible, which is set by a single call, in the desktop onboarding only (packages/desktop/src/renderer/onboarding.tsx → settings.general.setOldLayoutEligible(...)). The Web app never sets it, so the row is permanently hidden and the user is locked in.

Root cause

Two independent gaps:

1. The new layout shipped without porting the workspaces feature.
2. Layout-revert eligibility is only populated by desktop onboarding (window.api.isOldLayoutEligible()), leaving Web users with no escape hatch before the 2026-09-14 sunset.

Workaround

Flip the persisted setting directly in the browser console:

const d = JSON.parse(localStorage.getItem("settings.v3") || "{}")
d.general = d.general || {}
d.general.newLayoutDesigns = false
d.general.layoutTransitionEligible = true
localStorage.setItem("settings.v3", JSON.stringify(d))
location.reload()

Impact

Any Web user who relied on workspaces loses the feature on upgrade with no in-app recovery path. Feels like a regression rather than an intentional migration.

Suggested fix

• Port workspaces (sidebar project context menu + "Toggle workspaces" command) to the new layout, and/or
• Set layoutTransitionEligible for Web users too (or unconditionally show the revert toggle until sunset) so there's always an in-app way back.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• New Workspace sessions stall forever under the new layout — worktree.ready listener only lives in the legacy layout #36731: New Workspace sessions stall forever under the new layout — worktree.ready listener only lives in the legacy layout (overlapping root cause: worktree/workspace functionality missing from the new layout)
• [FEATURE] : keep legacy layout option #37012: [FEATURE]: keep legacy layout option (overlapping: no in-app way to revert to legacy layout)

[ma5d]

牛逼，确实可以

[dleopold]

I opened #38117 to address the web layout-transition eligibility gap described here. It intentionally does not address workspace parity in the new layout.

[markuest]

i can confirm this regression. as someone who is heavily using opencode web with workspaces i am stuck at v1.17 until this is fixed

[lz-migra]

Adding a use case that strengthens the case for keeping the toggle reachable in Web: I run opencode serve headless on a home box and connect to the Web UI from my phone's browser as my primary way to drive sessions while away from the desk.

For mobile Web users in general, the localStorage workaround posted above is effectively unreachable:

• Mobile Safari/Chrome do not expose DevTools on-device.
• Remote-debug workarounds (Mac + Web Inspector, or Android Chrome's chrome://inspect) all require a tethered desktop.
• No current mobile browser lets you paste/run arbitrary JavaScript against an open page.

So when the new layout auto-enables after a server upgrade, on mobile there is literally no escape hatch — no tap target, no command palette entry, no settings row. The UI either works or it doesn't. Many of my recent sessions (small screens, agent switcher visibility, side panel with workspaces) have been unusable on the v1.18.x new layout, which is why I'm blocked on the toggle staying out of Web entirely.

A few related pain points I hit specifically because there is no in-app control on Web:

• The agent selector button disappeared from the composer in v1.15.6 (web: agent selector button missing from prompt toolbar in v1.15.6 #28769). Switching agents now requires typing /agent name each session, which on a phone keyboard is friction-heavy.
• The "Plan/Build" agent pill vanished in v1.15.9 desktop parity ([TUI] Plan/Build agent selector disappeared after update; stuck on "Select an agent and model" prompt #28908).
• 2026-09-14 sunset for the toggle is fine — please just make sure Web users get the same Settings → General → "Use new layout" row, on or before that date, with layoutTransitionEligible set server-side for Web clients too (not only desktop onboarding).

Glad to see #38117 targeting the eligibility side. If anything in #38124 or the layout transition infra needs a Web-only QA tester on mobile browsers, happy to help.

Thanks @dleopold for picking this up so quickly.