feat(warp): present jcode as a first-class Warp CLI agent (OSC 777 status + notifications)

Summary

Make jcode present itself as a first-class Warp third-party CLI agent when
run inside Warp: emit the structured OSC 777 warp://cli-agent notifications
Warp uses to drive its agent toolbelt, per-tab working/done/blocked status, and
in-app + desktop notifications.

Today, running jcode inside Warp works but stays a "plain" process: Warp only
lights up its agent UI for a hardcoded list of agents (Claude Code, Codex,
Gemini, OpenCode, Auggie, Droid, Pi, oh-my-pi, Warp TUI). jcode is not on that
list, so no toolbelt, no status, no notifications.

I have a working implementation + tests and would happily turn it into a PR;
opening as an issue since external PRs are currently closed. A ready-to-apply
patch is attached/linked below.

How Warp's protocol works (verified against source)

From warpdotdev/warp master:

• crates/warp_core/src/cli_agent_protocol.rs - sentinel + schema
• app/src/terminal/cli_agent_sessions/* - listener bootstrap + event mapping

Key facts:

1. Warp bootstraps its agent session/listener from the OSC event alone
   (view.rs::handle_cli_agent_notification -> register_cli_agent_listener_from_event).
   No command-name match is required.
2. Warp only renders rich status/notifications for agents whose payload agent
   field resolves (via CLIAgent::command_prefixes) to one on its
   is_agent_supported list. An unknown value degrades to CLIAgent::Unknown,
   which gets no status listener.

Wire format:

ESC ]777;notify;warp://cli-agent;{JSON} BEL

JSON schema (v1, skip-none): {v, agent, event, session_id, cwd, project, query, response, transcript_path, summary, tool_name, tool_input, plugin_version, error_type}. Events: session_start, prompt_submit, stop, stop_failure,
permission_request, idle_prompt, etc.

Detection: Warp exports WARP_CLI_AGENT_PROTOCOL_VERSION on the PTY; its
presence is the signal that structured notifications are supported.

Design decision worth flagging

Because jcode is not on Warp's built-in list, the payload advertises a
supported identity so the UI activates. Default is pi (an open-source CLI
agent, closest neutral fit), configurable via [warp] cli_agent_identity.

This is a deliberate, documented workaround, not a clean end state. The proper
long-term fixes are either:

• Warp adds jcode to its supported-agent list (so we can send
  agent: "jcode" with a real icon), or
• Warp ships user-configurable custom agents (tracked in warpdotdev/warp#8579).

Happy to switch the default identity or gate differently based on maintainer
preference.

What the change does

New module jcode-base/src/warp_agent.rs:

• Warp detection (WARP_CLI_AGENT_PROTOCOL_VERSION).
• OSC 777 emitter matching Warp's CLIAgentNotification schema (v1, skip-none).
• A pure, unit-tested transition machine:
  • idle -> working = prompt_submit
  • working -> idle = stop, or stop_failure when a failure was latched
  • guards against a phantom stop before any turn runs
• Test-support capture sink so the emission path can be asserted without a PTY.

Config (jcode-config-types): [warp] cli_agent_integration (default true)
and cli_agent_identity (default "pi").

TUI wiring: session_start handshake on launch (both the local and remote run
loops), turn-boundary + per-tick state sync, and a stop_failure latch on turn
error.

The integration is a no-op outside Warp and when disabled in config.

Tests / verification

• 13 jcode-base unit tests, incl. the pure transition machine and an
  end-to-end test that drives the real emit() path and asserts
  session_start -> prompt_submit -> stop / stop_failure.
• 2 jcode-tui App-level integration tests through the real sync_warp_agent()
  method both run loops call (success + failure lifecycles, and replay-mode
  silence).
• Live PTY run through the actual launcher inside a Warp-like env:
  emits {"v":1,"agent":"pi","event":"session_start",...}; stays silent in a
  normal terminal and when cli_agent_integration = false.

Files changed

crates/jcode-base/src/warp_agent.rs            (new)
crates/jcode-tui/src/tui/app/warp_agent.rs     (new)
crates/jcode-base/src/config.rs
crates/jcode-base/src/lib.rs
crates/jcode-config-types/src/lib.rs
crates/jcode-tui/src/tui/app.rs
crates/jcode-tui/src/tui/app/local.rs
crates/jcode-tui/src/tui/app/model_context.rs
crates/jcode-tui/src/tui/app/remote.rs
crates/jcode-tui/src/tui/app/run_shell.rs
crates/jcode-tui/src/tui/app/remote_tests.rs

Patch / branch

Single-commit branch on my fork, applies cleanly on v0.62.1:

• Branch: https://github.com/vietgs03/jcode/tree/feat/warp-cli-agent-integration-062
• Commit: https://github.com/vietgs03/jcode/commit/232f4581cfa625ef43455376e2315a0600e01a05

Since external PRs are collaborators_only, a maintainer can cherry-pick the
commit directly, or I can open a PR if granted access. Happy to adjust anything
(default identity, config shape, gating) to match project conventions.

Environment

• jcode v0.62.1
• Warp v0.2026.07.22 stable, Linux x86_64

Start with the proposed jcode-base/src/warp_agent.rs and the TUI wiring in crates/jcode-tui/src/tui/app/warp_agent.rs, then review the config changes in jcode-config-types and the local and remote run loops. Run the listed jcode-base unit tests and jcode-tui App-level integration tests. Done means the Warp lifecycle events are emitted in Warp, remain silent elsewhere or when disabled, and replay mode stays silent.