[FEATURE] Make session panes (Files, Browser) usable before the first message is sent

[FEATURE] Make session panes (Files, Browser) usable before the first message is sent

Summary

In the Code tab, the session panes (Files, Browser, Diff, Terminal, iOS Simulator) only become available after the first prompt has been sent. On a freshly created session they are inert, in the session-toolbar Views menu and in the macOS menu bar alike. The keyboard accelerators (Cmd+Shift+B, Shift+Cmd+F, Cmd+Shift+D, Ctrl+\`) are dead too, since they are registered on those same disabled menu items.

Why this matters

Composing a good first prompt is exactly when I most need to look at things: browse the project tree to name the right files, or open a doc/issue page in the Browser pane to reference it. That work happens before the session starts, which is precisely the window where the panes are unavailable.

The result is a chicken-and-egg loop: to get the panes I must send a message, but the message I want to send is the one I need the panes to write. The workaround is to send a throwaway . just to boot the session, then discard the turn and type the real prompt.

Steps to reproduce

1. Code tab → + New session (Cmd+N), select a local folder.
2. Before sending anything, open the session ⋮ menu, or the macOS View menu.
3. Pane entries (Files, Browser, iOS Simulator) are unavailable.
4. Press Cmd+Shift+B or Shift+Cmd+F — nothing happens.
5. Send any message. The panes and their shortcuts become available immediately.

Expected: panes can be opened as soon as a session exists and a working directory is selected — the folder is already known at that point, so the Files pane has everything it needs to render.

Actual: panes are gated on the session having started.

Possible root cause

From a quick look at the shipped bundle (app.asar), the View-menu pane items are built by a shared factory whose enablement is derived from live session pane state rather than from the selected working directory:

enabled: n && state.enabled,
click:   () => dispatchToggleSessionPane(paneId)

Because the accelerators are registerAccelerator properties on those same items, a disabled item silently disables its keyboard shortcut as well — which is why there is no way around the menu.

Worth noting for contrast: the Command Palette… item (Cmd+K) in the same builder carries no enabled condition.

Suggested fixes (any one would resolve it)

1. Enable the Files pane as soon as a working directory is selected — it only needs a path, not a running agent.
2. Enable the Browser pane unconditionally for a session; external browsing does not depend on the agent process either.
3. Failing either, spawn the session eagerly on creation rather than lazily on first message.

Environment

• Claude Desktop 1.40609.0
• macOS 26.6.2 (build 25G83), Apple Silicon (arm64)
• Local session, git repository