spec: launch configs that open at app startup (#9203)#10018
spec: launch configs that open at app startup (#9203)#10018lonexreb wants to merge 1 commit intowarpdotdev:masterfrom
Conversation
Adds product.md and tech.md for issue warpdotdev#9203: a per-LaunchConfig "Open at startup" toggle so users can have their daily workflow layout materialize on every Warp launch. The Launch Configs feature already serializes a multi-window, multi-tab, multi-pane layout with per-pane CWDs, start commands, and pane modes. The data model was designed for this exact use case; only the *time of application* is missing. This spec is a focused additive change: V1 scope: - New `auto_launch_at_startup: bool` field on `LaunchConfig` with `#[serde(default)]` so existing on-disk configs deserialize unchanged - Startup hook in app_state init, fired after restore-previous-tabs, enumerates flagged configs and applies them via the existing apply_launch_config entry point - Toggle on the existing Launch Configs list row (no new settings page) - Failure handling: missing CWDs → fallback + notification; corrupt records → skip + notification; never block app startup - Composes with restore-previous-tabs (additive, not replacing) Out of V1 (tracked as follow-ups): - Time-of-day or per-day scheduling - Conditional auto-launch (CWD- or git-anchored) - Workspace-folder-anchored auto-launch (IDE integration) - Dedicated "Startup order" UI - Auto-detection of overlap with restore-previous 10 testable behavior invariants. Implementation surface is genuinely small: one struct field, one new hook, one toggle. Reuses existing launch-config persistence, application path, and notification routing.
github-actions
Bot
added
the
external-contributor
|
I'm starting a first review of this spec-only pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
![oz-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
There was a problem hiding this comment.
Overview
Reviewed the product and tech specs for per-launch-config startup auto-launch. The feature direction matches the linked issue, but the current spec assumes UI and ordering primitives that are not present in the launch-config implementation and understates the security impact of moving saved command execution from manual invocation to app startup.
Concerns
- Startup ordering depends on a user-assigned drag-and-drop list order, but the existing launch-config path loads YAML files and renders command-palette results without a persisted ordering model.
- The toggle is assigned to an existing Launch Configs list row, but the current command-palette surface is not a management list with per-row controls.
- The tech spec says there are no new shell interactions even though auto-launch can execute saved launch-config commands implicitly at startup.
Security
- Auto-launching a config that contains saved commands, or a config that is later edited on disk to add commands, creates a startup-time command execution surface that needs explicit confirmation/warning and safe handling requirements.
Verdict
Found: 0 critical, 3 important, 0 suggestions
Request changes
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
|
|
||
| ### Ordering multiple auto-launch configs | ||
|
|
||
| The Launch Configs list lets the user reorder rows via drag-and-drop (existing affordance, V0 simply respects the existing list ordering). Auto-launch configs open in list order on startup. There's no separate "startup order" UI in V1 — keeping the surface simple matches the issue's importance level (the reporter rated this 2/5). |
There was a problem hiding this comment.
HashMap, so startup order is undefined unless the spec adds persisted ordering or defines a deterministic fallback.
|
|
||
| ### 4. UI toggle | ||
|
|
||
| **File:** the existing Launch Configs list view (locate via `grep -rn "LaunchConfig" app/src/search/command_palette/launch_config/`). Each row gains a toggle component. |
There was a problem hiding this comment.
auto_launch_at_startup before implementation.
|
|
||
| - The `auto_launch_at_startup` boolean serializes identically across all platforms. | ||
| - Working-directory fallback semantics are inherited from the existing manual `apply_launch_config` path; this PR doesn't change them. | ||
| - No new file-system, network, or shell interactions. |
There was a problem hiding this comment.
commands at app startup, so this is a new shell-execution timing surface; replace this with requirements for user confirmation/warning and safe handling when an already-enabled YAML is edited to add commands or agent/cloud panes.
1 participant
Adds a product+tech spec for #9203: a per-Launch-Config "Open at startup" toggle so users can have their daily workflow layout materialize on every Warp launch.
Files
specs/GH9203/product.md(122 lines) — V1 scope, user experience, configuration shape, 10 testable behavior invariantsspecs/GH9203/tech.md(220 lines) — implementation plan, startup hook integration, UI toggle wiring, end-to-end flowTotal: 342 insertions, 0 deletions. No code changes — this is a spec PR.
Why this is small
The Launch Configs feature already serializes a multi-window, multi-tab, multi-pane layout with per-pane CWDs, start commands, and pane modes.
LaunchConfig::from_snapshotandapply_launch_configexist and are exercised today by the command-palette/launch-config <name>trigger. The data model was designed for this exact use case; only the time of application is missing.This spec adds:
LaunchConfig(auto_launch_at_startup) with#[serde(default)]so existing on-disk configs deserialize unchanged.apply_launch_configon each.That's it. No new persistence, no new application path, no new settings page.
V1 scope
AtomicBool.Out of V1 (tracked as follow-ups)
Why this spec
ready-to-spec, no existing PR claims it.ready-to-specissues — the data model and application path are already built; this is the smallest possible addition that delivers the user-visible feature.Open questions for maintainers
ToastStackfor failure notifications. Confirm at implementation time.AtomicBoolin thestartup.rsmodule vs. on the hook's input context. Implementation-time choice.Happy to iterate on the design or tighten the V1 scope further.