Follow up Warp upstream updates: standalone Agent CLI config root (~/.warp_cli/) unsupported — add a warpcli target

[dyoshikawa]

Summary

Warp shipped a standalone Agent CLI with its own config root, separate from the Warp app: CLI settings, MCP, and permissions live under ~/.warp_cli/ (platform variants), and the docs state "the app and the CLI keep separate settings files, so changing one never affects the other." rulesync's warp target writes only the app's paths, so a CLI user cannot sync MCP or permissions at all. Proposed: a new warpcli target (copilot/copilotcli precedent). Two implementation caveats — one affecting the existing warp target — are recorded below.

Recent Releases

• 2026-07-23 release (v0.2026.07.22.09.01) — warp-tui renamed to warp (PR #13904), establishing the standalone Agent CLI.
• Execution profiles opened to all users 2026-07-31 (already followed via Follow up Warp upstream updates: permissions inert after execution_profiles migration (Stable 2026-07-28), global ~/.agents/AGENTS.md rules not emitted #2512/Warp: author execution-profile autonomy keys (read_files, directory_allowlist, mcp allow/deny) — legacy warp override goes inert on migrated installs #2518).

Gaps

1. mcp + permissions — the Agent CLI's config root is unreachable

• Upstream (CLI configuration, CLI permissions & profiles):
  • CLI settings: macOS ~/.warp_cli/settings.toml, Linux ~/.config/warp-terminal/cli/settings.toml (respects $XDG_CONFIG_HOME), Windows %LOCALAPPDATA%\warp\Warp\config\cli\settings.toml
  • CLI MCP: ~/.warp_cli/.mcp.json — "keeps its own MCP server configuration, separate from the Warp app's"
  • CLI permissions: [agents.execution_profiles.default]; the CLI always runs the default profile.
• rulesync: only app paths exist (src/constants/warp-paths.ts: .warp, .config/warp-terminal, AppData/Local/warp/Warp/config); grep -rn "warp_cli" src/ returns nothing. Rules and skills already work for the CLI because both surfaces share AGENTS.md / .agents/skills/ with the app.
• Follow-up: add a warpcli target (copilot/copilotcli precedent in src/types/tool-target-tuples.ts) scoped to mcp (global, ~/.warp_cli/.mcp.json) and permissions (global, CLI settings.toml); deliberately leave rules/skills/commands/ignore to warp.

2. Caveat affecting the existing warp target too — command_denylist replaces the built-in denylist

The docs warn: "Setting command_denylist replaces the built-in default denylist, which covers rm, curl, wget, eval, ssh, shells, and other risky command patterns" (permissions & profiles). rulesync generates that array wholesale from canonical deny rules, so one authored deny rule silently removes the built-in protections. Warrants at minimum a generate-time warning.

3. Caveat for the CLI implementation — no migration guard applies

mergeIntoDefaultExecutionProfile() (src/features/permissions/warp-permissions.ts) only merges when [agents.execution_profiles] already exists — correct for the app (avoids pre-empting Warp's migration), but the CLI's settings.toml is "created the first time you change a setting" and is usually absent on a fresh install. The CLI path needs to create the collection directly.

Verified in parity

Rules, ignore (.warpindexingignore), commands/skills (/{skill-name}, $ARGUMENTS/$0), and the two sentinel non-surfaces re-checked: Warp still ships no hook configuration, and subagents remain runtime /orchestrate constructs (the file-visible run_agents permission is already covered by the warp.execution_profile override).

Housekeeping: references/warp.md:10 in the research skill lists global MCP as ~/.agents/.mcp.json; Warp's own global file is ~/.warp/.mcp.json (the implementation is correct; the map row is stale).

References

• https://docs.warp.dev/cli/configuration/ — separate CLI config root, paths, .mcp.json
• https://docs.warp.dev/cli/permissions-and-profiles/ — default profile + denylist-replacement warning

[dyoshikawa]

Triage note (2026-08-06): fact-checked against upstream docs, left open pending a maintainer decision.

Verified against https://docs.warp.dev/cli/configuration/ and https://docs.warp.dev/cli/permissions-and-profiles/: the standalone Agent CLI keeps fully separate config (macOS ~/.warp_cli/settings.toml, Linux ~/.config/warp-terminal/cli/settings.toml, Windows %LOCALAPPDATA%\warp\Warp\config\cli\settings.toml; MCP at ~/.warp_cli/.mcp.json), always runs the reserved default profile, and grep -rn warp_cli src/ is empty — the gap is real.

Decisions for a maintainer before implementation:

1. Whether to add a new warpcli target (copilot/copilotcli precedent) vs extending the existing warp target's global scope to the CLI paths — and which features it should cover.
2. The mergeIntoDefaultExecutionProfile() migration guard in warp-permissions.ts only merges when [agents.execution_profiles] already exists; a fresh CLI install has no settings.toml, so the CLI variant would need to intentionally drop that guard — a deviation worth an explicit sign-off.

Separable from the target decision: the command_denylist caveat (rulesync generates the array wholesale from canonical deny rules, silently replacing Warp's built-in denylist covering rm/curl/ssh/shells). A generate-time warning on the existing warp target is a small independent safety fix and may be handled separately.

[dyoshikawa]

Shipped the denylist-replacement warning in #2625. Warp's docs (https://docs.warp.dev/cli/permissions-and-profiles/) state that setting command_denylist replaces the built-in default denylist covering rm, curl, wget, eval, ssh, shells and other risky patterns, and rulesync generates that array wholesale — so one authored deny rule was silently dropping those protections. Generate now warns whenever a non-empty denylist is written, and docs/reference/file-formats.md documents the semantics.

Still not addressed here: a dedicated warpcli target remains design-gated per the earlier disposition comment.