You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue makes Maka an ACP client, allowing users to run an external agent inside Maka Desktop. Google Antigravity is the first concrete integration and acceptance case.
Users need to select an external execution agent, authenticate it, and use it through Maka's existing conversation interface. Adding each agent as a bespoke chat integration would duplicate session, interaction, history, and UI logic. Treating a complete external agent as an AI SDK model provider would also conflate agent-owned execution with Maka-owned model/tool execution.
This work does not expand the server scope of #3132 or restore the retired gemini-cli / Antigravity account-provider preview from #3054. The new integration uses Google's official ACP agent as a separate execution backend.
Desired outcome
User-visible result
A user can configure a locally installed official Antigravity ACP executable, sign in with Google, select Antigravity and a model in the Maka Desktop composer, and complete a coding task through Maka. The existing conversation surface shows streamed replies, tool activity, output, file diffs, permission choices, and agent questions. The user can stop execution and, after restarting, resume the same external session.
The Antigravity process runs behind Maka; this does not embed the Antigravity IDE.
Desktop design: a unified executor and model picker
Extend the existing composer model entry instead of adding a separate “Maka vs. external agent” toggle. The trigger shows the selected executor icon and model. Its popover has an executor rail on the left and that executor's model choices on the right:
[Executor icon · Model name v] [Supported mode v]
+--------------------+--------------------------------+
| Execution agent | Search models |
| | |
| * Maka | Models for this executor |
| Antigravity | Model A |
| | * Model B |
| | Model C |
| | |
| Manage agents | Connection state / setup |
+--------------------+--------------------------------+
Selecting the left rail browses an executor; selecting a model commits the complete executor/model choice and closes the popover.
The Maka branch retains its existing connection groups and model choices. The Antigravity branch uses models returned by its account/session configuration, without inventing an LLM connection.
An unconfigured or unauthenticated Antigravity entry can show setup/login actions, but cannot be committed as an executable selection.
Initially, Maka does not override the model or mode: use the current values returned when the ACP agent creates a session. Show the concrete values when available and an honest “Agent default” label otherwise. This does not promise to inherit the user's Antigravity IDE model selection. Verify that omission is supported; if the agent requires explicit configuration, include the necessary selection and application in PR 2 rather than deferring them to PR 4.
New drafts retain Maka's existing defaults. Do not add new global remembered-selection or project-precedence rules in this scope.
Switching executors preserves draft text and attachments. Unsupported attachments remain visible with an actionable validation message; they are not silently removed or sent.
Once a task exists, its executor is fixed. Model changes are allowed only while idle and when supported. Other executors explain that switching requires a new task.
Do not copy T3's favorites, multi-account management, or entire advanced-settings surface.
Desktop surface
Change
Settings
Add External Agents for official installation or existing-program selection, connection checks, Google sign-in, and diagnostics.
Composer
Extend the existing model entry with the unified picker; show only supported mode controls.
Conversation
Reuse existing message, tool-output, and diff presentation.
Interaction area
Reuse forms for external permission options and agent questions.
Task/history surface
Identify the executor and show interrupted, restoring, and restore-failed states.
Task Entry continues to supply the Host/project target. Executor selection and submission belong to the existing composer/task-creation flow, not a new responsibility inside Task Entry.
Architecture: Plugin-backed ACP executors
PR #5283 changed the extension seam after this issue was written. External execution is selected by Session.executorId and routed through the generic Plugin executor authority. ACP is now a Plugin-owned runtime behind that seam, not a second Host backend registry.
ACP SDK/stdio, process ownership, ACP Session lifecycle, file callbacks, cancellation, common configuration, and event projection.
Agent adapter Plugin
Executor identity, executable/helper, environment, authentication/model quirks, and provider-specific event interpretation.
Desktop
Generic executor/model presentation and task-creation intent; no Antigravity-specific conversation state.
PR #5164 remains the merged installation/authentication bootstrap. Until Plugin configuration and authorization have a complete Desktop contribution surface, PR 2 bridges its RuntimePolicy facts into a system-managed Antigravity adapter Entry. This bridge must not become a parallel execution path.
The official ACP SDK is used rather than reimplementing JSON-RPC. Future ACP Agents implement the adapter contract and reuse the runtime; non-ACP Agents can register another generic Plugin executor. Every production contract must ship with its real producer and consumer in the same PR.
Protocol, interaction, and lifecycle rules
Use a local stdio connection and one external process per active task, owned by the Host. In PR 2, an active task includes a live session waiting for its next turn: retain its process while idle. Closing the UI does not implicitly stop a task. Retirement and Host shutdown clean up owned processes, including owned helpers. PR 2 must handle crashes, cancellation races, and cleanup itself; process loss leaves readable history with continuation explicitly unavailable until restoration is delivered.
Convert text, tool activity, output, diffs, and completion into existing backend events. Merge partial updates by tool-call ID and preserve arrival order. Add shared event fields only with a same-PR producer and consumer.
External tool notifications are observations, not instructions for Maka to execute the same tool. Do not fabricate Maka tool-dispatch journal entries.
Use HostedInteractionBridge.admitFormRequest for external option-based interactions. Map the ACP option ID to the form's single_select.value and its display text to label; return the original ID through the existing settlement path.
Clearly identify external permission requests and preserve the agent's allow/deny choices. Do not reinterpret them as Maka sandbox grants or route them through legacy permission events. Antigravity-specific question detection stays in its adaptation code.
Implement the verified, necessary ACP text-file callbacks with workspace/path/symlink checks. Do not advertise terminal capability. Do not claim that agent-owned tools run inside Maka's built-in sandbox.
Cancellation settles outstanding interactions, sends ACP cancel, and continues consuming updates until the prompt finishes. A bounded timeout terminates the owned process and records interruption rather than false successful cancellation. Preserve the actual stop reason.
Maka stores visible history; the external agent owns its execution context. A crash does not automatically resend a prompt.
Restore through negotiated resume/load support. Load replay is handled as restoration, not appended as a new turn. Define replay deduplication and reconciliation when the agent has progressed beyond Maka's last durable event; do not blindly discard or append all replay. If history cannot be reliably aligned, show an explicit history-gap/restoration status instead of claiming intact history. Failure keeps history readable and offers retry/new task without silently replacing the external session or resending a prompt.
Use a Maka-managed or user-installed official Antigravity ACP distribution, including its matching helper. The official process owns credentials. Do not assume IDE login is reusable.
PR1 setup behavior has now been exercised with official ACP 1.1.1 on macOS arm64; see #5164. Task execution, model/mode and restoration behavior are not established by these setup checks. Record and verify the actual version/platform, authentication, event shapes, cancellation, and restoration before relying on them. T3's Antigravity adapter is an implementation reference, not a substitute for real-agent acceptance.
Pre-implementation verification
Verify the official binary before implementing the behavior that depends on it; record the actual version/platform and sanitized evidence. Reference code and negotiated protocol support do not replace real-agent checks.
Before PR 1 authentication: verify official server/helper layout, initialization, authentication methods, authorization-link output, authentication completion and process exit. Connection checks must not log in, create a session or send a prompt. PR1 setup evidence is recorded in feat(desktop): install and configure Antigravity ACP #5164.
Before PR 2 execution: verify session creation, omitted model/mode initialization, required file callbacks, text/tool/diff/permission/question events, multi-turn prompting and cancellation. Probe cross-process resume/load feasibility here as well, so the task binding does not assume unverified restoration behavior.
Before PR 3 restoration: verify restoration of the same session across process restarts, replay shape, deduplication and crash-window reconciliation before implementing persistence/restoration behavior.
Before PR 4 configuration: verify actual model/mode discovery, selection/application and failure behavior. Configuration required to execute belongs in PR2 and must be verified there.
If required behavior is unavailable, revise that PR's scope and acceptance criteria before implementation. Do not record credentials or private project content. Completing PR1 setup checks does not mark task, model or restoration behavior as verified.
Incremental PR plan
The roadmap remains four PRs: PR 1 setup/authentication → PR 2 complete Plugin-backed execution and usable model selection → PR 3 restoration → PR 4 modes and catalog lifecycle. PR 2 stays one vertical PR. Its work is grouped into four reviewable producer-to-consumer sets; no group is complete until its producer, contract, consumer, and acceptance test are all present.
Install or select the official Antigravity ACP distribution, verify it, and persist executable facts through RuntimePolicy.
Check connectivity and complete Google authentication without creating a task or sending a prompt.
Clean up temporary server/helper processes and cover integrity, persistence, stale-result protection, localization, diagnostics, and real macOS arm64 setup evidence.
Transition boundary: PR 1 produces setup/authentication facts; PR 2 consumes them to materialize Plugin configuration. PR 1 never executes a task.
Add the shared ACP Runtime Plugin and thin Antigravity adapter contract.
Ship both production Plugin bundles with Runtime Host/Desktop and project the PR 1 executable/helper path into content-addressed, system-managed packages and an adapter Entry without exposing RuntimePolicy authority to either Plugin.
Project unavailable and authentication-required readiness through the generic executor catalog/inspection consumed by Desktop before Session creation (owned by Set B).
Set B — provider catalog → Desktop choice → first ACP prompt
Add a generic executor catalog/configuration contract with an Antigravity producer and Desktop consumer. Discovery may use a bounded short-lived ACP probe but must not create a Maka task or retain a preview Session/process.
Extend the existing upstream/main model menu with generic executor browsing and model selection; preserve draft text, attachments, and Maka model state.
Atomically persist executor plus selected model at task creation and consume that exact value when creating the ACP Session before its first prompt. Existing tasks keep a fixed executor and confirmed model; unavailable values are never silently replaced.
Connect unconfigured, unavailable, and login-required catalog states to PR 1 setup before Maka Session creation.
Set C — ACP updates/interactions → canonical conversation → ACP settlement
Add generic Agent-question interaction support; keep provider-specific detection in the adapter and round-trip original option identity through Hosted Forms.
Ensure unsupported attachments/native-only operations remain visible with actionable validation and do not delete draft content.
Set D — process continuity facts → safe task readiness
Persist a continuity marker and refuse silent replacement after Host/Plugin restart or process loss.
Project history-only/process-lost readiness through generic Session/Desktop state with retry/new-task guidance; loading history must not launch an Agent.
Repeat sanitized controlled-process and official Antigravity acceptance on the rebuilt Plugin path, including authentication, model application, task isolation, follow-up, interactions, cancellation, and process loss.
End-to-end producer → consumer: PR 1 setup facts → system-managed adapter Entry → provider catalog/configuration → generic Desktop executor/model choice → Session executorId and config → Plugin executor → canonical events/Hosted Forms → follow-up, model change, stop, or history-only readiness.
Acceptance: the official Agent completes the Desktop flow through follow-up and cancellation; multiple tasks reuse catalog data but own independent Sessions; restart remains explicit history-only until PR 3.
PR 3 — Restore the same external Session and reconstruct its process — planning started on 2026-09-24; implementation begins with the real-Agent restoration verification gate.
Verify cross-process resume/load and replay behavior against the supported official Antigravity version.
Extend the ACP Runtime/adapter contract with durable external-session identity and explicit create-versus-restore paths; restoration never falls back to session/new.
Restore lazily on continuation, reconcile replay with canonical history, handle crash windows, and expose restoration/history-gap states without resending an interrupted prompt.
Acceptance: restart and continue the same real external Session with intact context and no duplicate history; failure remains readable and never creates a replacement Session.
PR 4 — Supported modes and model-catalog lifecycle
Reuse PR 2's generic executor catalog/configuration contract for modes; do not add another discovery path or Agent-specific picker.
Acceptance: selected model/mode affects execution, cached catalogs appear immediately, invalid choices are explicit, and refresh scope is correct.
Final acceptance criteria
With a recorded official Antigravity version, complete the Desktop path: configure → Google sign-in → select Antigravity/model → create task → edit and test → inspect tools/diffs → answer interactions → follow up → cancel → restart and continue the same external session.
Maka and every external Agent provide candidates through provider-owned catalog/configuration logic and render them through the same upstream/main-style model menu; adding another provider does not duplicate Composer or Host orchestration.
Selecting an external Agent exposes cached candidates immediately. Concurrent or subsequent new tasks reuse catalog data while keeping independent external sessions and selected configurations.
Existing tasks cannot switch executor. Model/mode changes are idle-only, Agent-confirmed, and never silently substituted after account/catalog changes.
Unsupported attachments and operations remain visible with actionable validation and never lose draft content.
Real-agent checks cover authentication, actual tools/session behavior, model/mode application, and cross-process restoration; fixtures contain no tokens or private project content.
Existing Maka execution remains functional, and shared ACP dependency changes preserve the maka --acp server path.
Every new production interface, field, or capability has a real same-PR consumer; shared behavior stays behind the provider/backend seams instead of spreading into Agent-specific UI branches.
Initial scope
Local Maka Desktop on macOS arm64, local Runtime Host, and an official Antigravity ACP process installed through an explicit Install action or selected by the user. Out of scope: automatic discovery/upgrades, remote execution/OAuth forwarding, multi-account management, external subagent orchestration, steering, rewind, and cross-agent continuation. TUI product work is deferred while the Host implementation remains reusable.
Alternatives or workarounds
Use Antigravity separately: possible today, but does not provide the unified Maka task/history/interaction experience.
Wrap Antigravity as an AI SDK model provider: rejected because a complete agent owns session state and tools, unlike a model call. Use a sibling AgentBackend implementation instead.
Build a separate external-agent chat stack: rejected because Maka already has execution, interaction, persistence, and presentation seams.
Embed the IDE or wrap the ordinary CLI: unnecessary for this scope because an official ACP distribution exists.
Implement infrastructure-only PRs before wiring UI consumers: rejected; the PRs above deliver vertical production slices.
This proposal was prepared with AI assistance from the design discussion. Real-binary verification remains an explicit implementation and acceptance requirement.
English
Problem
This is a follow-up tracking issue for #3132, specifically the ACP client / Antigravity use case.
The two directions are distinct:
maka --acp.Users need to select an external execution agent, authenticate it, and use it through Maka's existing conversation interface. Adding each agent as a bespoke chat integration would duplicate session, interaction, history, and UI logic. Treating a complete external agent as an AI SDK model provider would also conflate agent-owned execution with Maka-owned model/tool execution.
This work does not expand the server scope of #3132 or restore the retired
gemini-cli/ Antigravity account-provider preview from #3054. The new integration uses Google's official ACP agent as a separate execution backend.Desired outcome
User-visible result
A user can configure a locally installed official Antigravity ACP executable, sign in with Google, select Antigravity and a model in the Maka Desktop composer, and complete a coding task through Maka. The existing conversation surface shows streamed replies, tool activity, output, file diffs, permission choices, and agent questions. The user can stop execution and, after restarting, resume the same external session.
The Antigravity process runs behind Maka; this does not embed the Antigravity IDE.
Desktop design: a unified executor and model picker
Follow the interaction structure of T3 Code's ProviderModelPicker and ModelPickerSidebar, using Maka's existing UI primitives and styling.
Extend the existing composer model entry instead of adding a separate “Maka vs. external agent” toggle. The trigger shows the selected executor icon and model. Its popover has an executor rail on the left and that executor's model choices on the right:
Task Entry continues to supply the Host/project target. Executor selection and submission belong to the existing composer/task-creation flow, not a new responsibility inside Task Entry.
Architecture: Plugin-backed ACP executors
PR #5283 changed the extension seam after this issue was written. External execution is selected by
Session.executorIdand routed through the generic Plugin executor authority. ACP is now a Plugin-owned runtime behind that seam, not a second Host backend registry.PR #5164 remains the merged installation/authentication bootstrap. Until Plugin configuration and authorization have a complete Desktop contribution surface, PR 2 bridges its RuntimePolicy facts into a system-managed Antigravity adapter Entry. This bridge must not become a parallel execution path.
The official ACP SDK is used rather than reimplementing JSON-RPC. Future ACP Agents implement the adapter contract and reuse the runtime; non-ACP Agents can register another generic Plugin executor. Every production contract must ship with its real producer and consumer in the same PR.
Protocol, interaction, and lifecycle rules
HostedInteractionBridge.admitFormRequestfor external option-based interactions. Map the ACP option ID to the form'ssingle_select.valueand its display text tolabel; return the original ID through the existing settlement path.PR1 setup behavior has now been exercised with official ACP 1.1.1 on macOS arm64; see #5164. Task execution, model/mode and restoration behavior are not established by these setup checks. Record and verify the actual version/platform, authentication, event shapes, cancellation, and restoration before relying on them. T3's Antigravity adapter is an implementation reference, not a substitute for real-agent acceptance.
Pre-implementation verification
Verify the official binary before implementing the behavior that depends on it; record the actual version/platform and sanitized evidence. Reference code and negotiated protocol support do not replace real-agent checks.
If required behavior is unavailable, revise that PR's scope and acceptance criteria before implementation. Do not record credentials or private project content. Completing PR1 setup checks does not mark task, model or restoration behavior as verified.
Incremental PR plan
The roadmap remains four PRs: PR 1 setup/authentication → PR 2 complete Plugin-backed execution and usable model selection → PR 3 restoration → PR 4 modes and catalog lifecycle. PR 2 stays one vertical PR. Its work is grouped into four reviewable producer-to-consumer sets; no group is complete until its producer, contract, consumer, and acceptance test are all present.
PR 1 — Install, configure, connect, and authenticate from Settings — merged in feat(desktop): install and configure Antigravity ACP #5164.
PR 2 — Plugin-backed external-Agent execution and usable model selection — merged in feat(desktop): complete Antigravity ACP plugin execution #5224 on 2026-09-23 (
0cb4fc32bdff3587bd5cc609fbe0eb28efa4233f).Set A — setup facts → active Plugin executor
executorId,PluginExecutorService, andPluginExecutorBackendwithout ACP-specific Session/Core/Storage/backend-registry branches.Set B — provider catalog → Desktop choice → first ACP prompt
Set C — ACP updates/interactions → canonical conversation → ACP settlement
Set D — process continuity facts → safe task readiness
Persist a continuity marker and refuse silent replacement after Host/Plugin restart or process loss.
Project history-only/process-lost readiness through generic Session/Desktop state with retry/new-task guidance; loading history must not launch an Agent.
Repeat sanitized controlled-process and official Antigravity acceptance on the rebuilt Plugin path, including authentication, model application, task isolation, follow-up, interactions, cancellation, and process loss.
Complete full CI, final review, and merge feat(desktop): complete Antigravity ACP plugin execution #5224.
End-to-end producer → consumer: PR 1 setup facts → system-managed adapter Entry → provider catalog/configuration → generic Desktop executor/model choice → Session
executorIdand config → Plugin executor → canonical events/Hosted Forms → follow-up, model change, stop, or history-only readiness.Acceptance: the official Agent completes the Desktop flow through follow-up and cancellation; multiple tasks reuse catalog data but own independent Sessions; restart remains explicit history-only until PR 3.
Merge evidence: feat(desktop): complete Antigravity ACP plugin execution #5224 is merged; its reported checks have no failures (CLI Eval was skipped). Acceptance record. PR 2 execution reused an existing Google login; expired-auth recovery and complete cross-process restoration remain unverified. Bounded idle-process retention is tracked separately in Define bounded retention for ACP client processes #5620.
PR 3 — Restore the same external Session and reconstruct its process — planning started on 2026-09-24; implementation begins with the real-Agent restoration verification gate.
session/new.PR 4 — Supported modes and model-catalog lifecycle
Final acceptance criteria
Initial scope
Local Maka Desktop on macOS arm64, local Runtime Host, and an official Antigravity ACP process installed through an explicit Install action or selected by the user. Out of scope: automatic discovery/upgrades, remote execution/OAuth forwarding, multi-account management, external subagent orchestration, steering, rewind, and cross-agent continuation. TUI product work is deferred while the Host implementation remains reusable.
Alternatives or workarounds
AgentBackendimplementation instead.This proposal was prepared with AI assistance from the design discussion. Real-binary verification remains an explicit implementation and acceptance requirement.
中文
问题
这是 #3132 的后续追踪 issue，对应其中提出的 ACP client / Antigravity 使用案例。
两个方向需要区分：
maka --acp将 Maka 暴露为 ACP Agent / 服务端。用户需要选择外部执行者、完成认证，并通过 Maka 现有聊天界面使用它。如果每接入一个 Agent 都单独实现聊天集成，就会重复建设会话、交互、历史和 UI。如果将完整外部 Agent 当作 AI SDK 模型 provider，则会混淆外部 Agent 自己管理的执行循环与 Maka 管理的模型调用和工具执行。
本方案不扩大 #3132 的服务端范围，也不恢复 #3054 已退役的
gemini-cli/ Antigravity 账户 provider 预览。新的接入方式是将 Google 官方 ACP Agent 作为独立执行 backend。期望结果
用户最终看到的效果
用户配置本地安装的官方 Antigravity ACP 程序，完成 Google 登录，在 Maka Desktop 输入框中选择 Antigravity 和模型，然后通过 Maka 完成编码任务。现有聊天界面展示流式回复、工具活动、输出、文件 diff、权限选项和 Agent 提问。用户可以停止执行，并在重启后恢复同一个外部会话。
Antigravity 进程在 Maka 后台运行，不嵌入 Antigravity IDE。
Desktop 设计：统一的执行者与模型选择器
参考 T3 Code 的 ProviderModelPicker 与 ModelPickerSidebar 的交互结构，使用 Maka 已有 UI 基础组件与样式实现。
扩展现有 Composer 模型入口，不增加独立的“Maka / 外部 Agent”开关。按钮显示当前执行者图标和模型，展开后左侧切换执行者，右侧显示其模型：
Task Entry 继续提供 Host 与项目目标。执行者选择及提交属于现有 Composer / 任务创建流程，不向 Task Entry 加入新的会话创建职责。
架构：基于 Plugin executor 接入 ACP
本 issue 编写后，PR #5283 已提供新的通用外部执行 seam：由
Session.executorId选择执行者，并统一经过 Plugin executor 权威链路。ACP 现在位于该 seam 后方，由 Plugin 管理，不再向 Host 增加第二套 backend registry。已合入的 PR #5164 继续作为安装与认证 bootstrap。在 Plugin 配置和授权尚无完整 Desktop contribution surface 期间，PR 2 将其 RuntimePolicy 事实桥接为系统管理的 Antigravity adapter Entry；该桥接不能形成并行执行路径。
使用官方 ACP SDK，不重新实现 JSON-RPC。后续 ACP Agent 只实现 adapter contract 并复用共享 runtime；非 ACP Agent 可以注册其他通用 Plugin executor。每个生产契约必须在同一 PR 中交付真实生产者和消费者。
协议、交互与生命周期规则
HostedInteractionBridge.admitFormRequest。ACP option ID 映射为表单single_select.value，显示文本映射为label，通过现有结算路径回传原始 ID。PR1 设置流程已使用 macOS arm64 官方 ACP 1.1.1 实测，见 #5164；这些设置验证不代表任务执行、模型/模式及恢复行为已验证。实施时必须记录并验证实际版本、平台、认证、事件结构、取消和恢复行为。T3 的 Antigravity 适配是实现参考，不能替代真实 Agent 验收。
实施前真实能力验证
在实现依赖某项能力的功能前验证官方程序，记录实际版本、平台和脱敏证据。参考代码及协议能力声明不能代替真实 Agent 验证。
必要能力不可用时，先修改对应 PR 的范围和验收标准再实施。记录中不得包含凭据或私有项目内容。PR1 设置检查完成不代表任务、模型或恢复能力已验证。
PR 拆分实施计划
路线仍保持四个 PR：PR 1 设置/认证 → PR 2 完整 Plugin 执行闭环与可用模型选择 → PR 3 恢复 → PR 4 modes 与目录生命周期。PR 2 保持一个纵向 PR，不再拆分；其工作分为四组可审查的“生产者到消费者”最小集合。生产者、契约、消费者和验收测试未同时出现时，该组不得标记完成。
PR 1 — 在设置中安装、配置、连接与认证 — 已通过 feat(desktop): install and configure Antigravity ACP #5164 合并。
PR 2 — 基于 Plugin 的外部 Agent 执行闭环与可用模型选择 — 已于 2026-09-23 通过 feat(desktop): complete Antigravity ACP plugin execution #5224 合并（
0cb4fc32bdff3587bd5cc609fbe0eb28efa4233f）。集合 A — 设置事实 → 可用 Plugin executor
executorId、PluginExecutorService和PluginExecutorBackend重建，不增加 ACP 专属 Session/Core/Storage/backend-registry 分支。集合 B — provider 目录 → Desktop 选择 → 首条 ACP prompt
集合 C — ACP 更新/交互 → 权威聊天 → ACP 结算
集合 D — 进程连续性事实 → 安全的任务就绪状态
持久化连续性标记，在 Host/Plugin 重启或进程丢失后拒绝静默替换。
通过通用 Session/Desktop 状态投影 history-only/process-lost，并提供重试/新任务引导；加载历史不得启动 Agent。
在重建后的 Plugin 路径重新执行脱敏受控进程和官方 Antigravity 验收，覆盖认证、模型应用、任务隔离、追问、交互、取消及进程丢失。
完成完整 CI、最终 review 并合并 feat(desktop): complete Antigravity ACP plugin execution #5224。
端到端生产者 → 消费者： PR 1 设置事实 → 系统管理的 adapter Entry → provider 目录/配置 → 通用 Desktop executor/model 选择 → Session
executorId与配置 → Plugin executor → 权威事件/Hosted Forms → 追问、改模型、停止或 history-only 就绪状态。验收： 使用官方 Agent 完成 Desktop 全链路、追问和取消；多个任务复用目录数据但各自拥有独立 Session；在 PR 3 前，重启后保持明确 history-only。
合并证据： feat(desktop): complete Antigravity ACP plugin execution #5224 已合并，已报告的检查无失败项（CLI Eval 跳过）。验收记录。PR 2 执行验收复用了已有 Google 登录；认证过期恢复与完整跨进程恢复仍未验证。空闲进程保留上限单独跟踪于 Define bounded retention for ACP client processes #5620。
PR 3 — 恢复同一个外部 Session 并重建进程 — 2026-09-24 开始规划；实现首先通过真实 Agent 恢复验证前置门槛。
session/new。PR 4 — 支持的 modes 与模型目录生命周期
最终验收标准
首期范围
本地 macOS arm64 Maka Desktop、本地 Runtime Host，以及用户点击安装或手动选择的官方 Antigravity ACP 进程。不包含自动发现或自动升级、远程执行/OAuth 转发、多账户管理、外部子 Agent 编排、steering、会话回退或跨 Agent 续接。TUI 产品入口后续再做，Host 实现保持可复用。
备选方案或临时做法
AgentBackend。本提案依据设计讨论，由 AI 辅助整理。官方二进制实测仍是明确的实施与验收要求。