[Bug]: Browser tabs and terminal link clicks break for local worktrees while a remote runtime environment is focused

[gatsby74]

Operating system

macOS (reproduced here; the routing logic is platform-independent)

Orca version

1.4.146-rc.0 (current main)

Details

Short summary:
While a remote runtime environment is focused (e.g. a paired Mac Mini runtime), two related things break even for worktrees that are entirely local:

1. Agents cannot open links in the Orca browser via the Orca CLI. orca browser tab create <url> fails with Browser tabs are unavailable while a remote runtime is active.
2. Cmd/Ctrl-clicking an http(s) link in a terminal opens the system browser instead of an Orca browser tab, even though the terminal's worktree is local and openLinksInApp is enabled.

What happened?

• In a local workspace (repo and worktree owned by the local host), an agent asked to open a docs page in the Orca browser got the "unavailable while a remote runtime is active" error on every attempt.
• In the same configuration, Cmd-clicking a link printed in a local terminal opened the external system browser instead of an Orca tab.

How can we reproduce it?

1. Pair a remote runtime environment (Settings > Runtime environments) and focus it so activeRuntimeEnvironmentId is set.
2. Switch back to a worktree that is locally owned (no explicit runtime/SSH host).
3. Run orca browser tab create https://example.com → rejected with the error above.
4. Cmd-click an https link in a local terminal → opens in the system browser instead of Orca.

Root cause (investigated):

Routing decisions use the global runtime focus (settings.activeRuntimeEnvironmentId) instead of the owner of the worktree/pane the request came from:

• The renderer's browser:requestTabCreate, browser:requestTabClose, and browser:requestTabSetProfile IPC handlers blanket-reject whenever a runtime environment is focused (isRuntimeEnvironmentActive()). That guard predates headless remote browser panes (Refactor runtime app architecture #1878 vs Support browser panes on headless remote Orca servers #5412) and blocks local tabs too.
• Terminal http-link paths (OSC 8, WebLinks addon, mouseup fallback) call openHttpLink without a sourceOwner, so it infers locality from the global focus flag.
• CLI browser automation commands (browser snapshot/goto/click/...) resolve only against the desktop-local CDP bridge, so remote-hosted tabs (which the UI already supports via createWebRuntimeSessionBrowserTab) can't be operated by agents driving the desktop runtime.

Expected behavior:

• Local worktree + focused remote runtime → local Orca browser tabs work (create/close/automate), and terminal links open in Orca.
• Remote-owned worktree → CLI browser commands route to the owning environment's hosted browser (mirrored into the desktop UI), matching what the UI's "New Browser Tab" button already does.

Workaround: switch the active execution host back to the local machine before opening links.

[nwparker]

Repro status: has_repro (code-path, conclusive)

Summary

While a remote runtime environment is focused, local worktrees lose Orca browser tabs and terminal http-link in-app routing because decisions use the global focus flag / missing sourceOwner.

Code evidence

1. CLI browser tab create (src/renderer/src/hooks/useIpcEvents.ts ~2296–2306):

if (isRuntimeEnvironmentActive()) {
  reply error: "Browser tabs are unavailable while a remote runtime is active"
  return
}

No check whether the target worktree is local.

2. Terminal HTTP links (src/renderer/src/lib/http-link-routing.ts):

const remoteRuntimeActive = Boolean(state?.settings?.activeRuntimeEnvironmentId?.trim())
const sourceIsLocal = sourceOwner ? sourceOwner.kind === "local" : !remoteRuntimeActive

If callers omit sourceOwner, a focused remote runtime forces system-browser routing even for local terminals.

Repro

1. Focus a paired remote runtime environment.
2. Switch UI to a local worktree.
3. orca browser tab create https://example.com → rejected with the error above.
4. Cmd/Ctrl-click an https link in a local terminal with openLinksInApp → system browser.

Expected

Route by source worktree/pane owner, not global runtime focus alone.