Expose pane split + command execution via URI scheme

[jarek-tr]

Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates
• I have searched Warp docs and my feature is not there

Describe the solution you'd like?

Extend Warp's URI scheme to support pane splitting with an optional command:

warp://action/split-right?command=<url_encoded_command>
warp://action/split-left?command=<url_encoded_command>
warp://action/split-down?command=<url_encoded_command>
warp://action/split-up?command=<url_encoded_command>
warp://action/close-pane

One additional surface that would complete programmatic pane control:

warp://action/pane-focus?index=2
warp://action/pane-focus?direction=right
warp://action/pane-list  (returns JSON: pane count, active index, commands running)

Navigation + focus + introspection would enable full programmatic pane orchestration without any accessibility hacks.

This would also be consistent with the existing warp://action/new_window?path=... and warp://action/new_tab?path=... patterns.

Is your feature request related to a problem? Please describe.

There is currently no reliable way to programmatically create pane splits and run commands in them from an external process. The URI scheme supports windows and tabs but not panes. Developers building tools that orchestrate multiple terminal sessions in a single tab are forced into AppleScript/xdotool/AutoHotkey hacks.

Is there a workaround?

Yes, AppleScript keystroke injection targeting process "stable" with key codes (e.g., key code 2 using command down for split-right), followed by keystroke injection to type the command. This requires macOS accessibility permissions, timing delays between split and command entry, and geometry-relative click targeting (via cliclick) for teardown. It works but is fragile, macOS-only, and breaks if focus shifts during automation.

For context on the workaround: I'm currently using AppleScript key code injection (key code 2 using {command down} targeting process stable) with timing delays and cliclick for geometry-relative pane targeting during teardown. I'm considering replacing this with a Swift CLI tool wrapping AXUIElement Accessibility APIs for more reliable pane control — direct API calls, proper error handling, ability to query pane state. Both approaches are hacks around the missing URI surface. The URI would eliminate the need for either.

Additional context

Related issues: #8741 (CLI hooks for split panes), #6740 (programmatic GUI access for agent automation). The URI approach may be simpler to implement than a full CLI since the URI infrastructure already exists.

Operating system (OS)

macOS

How important is this feature to you?

5 (Can't work without it!)

Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1

None