Feature request: boolean/checkbox parameter type for tab configs

[tomerArzuan]

Summary

Tab configs currently only support text, branch, and repo parameter types. When a user wants to offer a simple on/off toggle (e.g., "set upstream automatically"), they have to use a text parameter and ask the user to type yes or no. This is clunky and error-prone. A native checkbox or boolean parameter type would make these workflows much cleaner.

Problem

In tab config TOML files, the [params.<name>] section supports only type = "text", type = "branch", and type = "repo". There is no way to present a simple true/false or yes/no choice as a checkbox or toggle in the parameter fill-in modal.

For example, a user might want a worktree tab config with an option like "Set upstream to base branch?" that is checked by default. Today the only workaround is:

[params.set_upstream]
type = "text"
description = "Set upstream to base branch? (yes/no)"
default = "yes"

This requires the user to type a magic string (yes/no) and relies on the shell author to write a conditional that checks for an exact string match. It also prevents the UI from rendering a compact, intuitive control.

Reproduction steps or desired workflow

1. Create or edit a tab config TOML file.
2. Add a parameter that should be a boolean choice.
3. Try to declare type = "checkbox" or type = "boolean" under [params.<name>].
4. Observe that the type is rejected or ignored because it is not in the supported set (text, branch, repo).

Desired behavior

A new parameter type — e.g., type = "boolean" or type = "checkbox" — that renders a checkbox in the fill-in modal and produces a true/false value that can be interpolated into commands.

Example usage:

[params.set_upstream]
type = "boolean"
description = "Set upstream to base branch"
default = true

In commands, the parameter could be referenced as {{set_upstream}} and evaluate to "true" / "false" (or 1 / 0), making it easy to use in shell conditionals without magic strings.

Artifacts

None attached

Warp version

Unknown

Operating system

macOS

[oz-for-oss]

@tomerArzuan

Here's what I found while triaging this issue:

This appears to be a valid feature gap: tab config params currently support only text, branch, and repo controls, and boolean defaults are not accepted by the current schema.

Maintainer details

I concluded that feature request to add a native boolean/checkbox parameter type for tab config fill-in modals instead of requiring text-based yes/no inputs..

Triage summary

This is a valid enhancement request for tab config parameters. The current schema and fill-in modal support only text, branch, and repo parameter modes, so authors cannot declare a native boolean/checkbox value today.

Code findings

• app/src/tab_configs/tab_config.rs defines TabConfigParamType with only Text, Branch, and Repo, and TabConfigParam.default is Option<String>, so default = true would not deserialize as a boolean default.
• app/src/tab_configs/params_modal.rs builds modal fields only for text editors, branch pickers, and repo pickers; there is no checkbox/switch field or boolean-specific value resolution.
• resources/bundled/skills/tab-configs/SKILL.md documents the same three supported parameter types, so docs/schema references would need to be updated if this is implemented.

Likely implementation shape

Implementation would likely require extending the tab config param schema with a boolean-like variant, deciding the TOML spelling (boolean vs checkbox), accepting boolean defaults, rendering a checkbox/switch in the params modal, and defining the command interpolation output (true/false or another stable representation).

Duplicate check

I enumerated open issues and ran targeted searches for boolean/checkbox tab config parameter requests. I did not find two or more likely duplicate issues, so this should remain a standalone feature request.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[oz-for-oss]

This issue has been labeled ready-to-spec and is open for contributions in the form of a product or technical spec. If you'd like to draft one, feel free to open a pull request with the spec under specs/. You can also comment @oz-agent on this issue to have the bot draft the spec automatically.