2 Commits

Include renames

Author	SHA1	Message	Date
Brennan Benson	e268135719	feat(native-chat): chat agents are offered wherever their chat program runs, not only where their CLI is installed (#28709) ... * feat(acp): ACP agents can declare a managed runtime installed on first chat start An ACP launch spec may name a pinned runtime Orca installs under its locked data folder. The stock lookup searches it last (Command, PATH, install directories, managed folder); a start whose lookup missed installs it under the acquisition's signal, then resolves the launch again. A Command setting, restart-recovery reads and catalog probes never install. The pinned-runtime materializer can now publish a verified multi-member folder: extract once into staging, check each member's sha256, rename into place, with a per-asset download size limit. Node's runtime path is unchanged. * Fix ACP managed runtime lookup precedence * feat(acp): ACP agents can run with a private per-process temp folder * feat(acp): old managed runtime versions are removed at host start Once per host start, the ACP registration removes every version beside an agent's current managed runtime folder, and staging left by an earlier process. One host owns the data root and ACP servers are never reattached across host runs, so nothing runs from them. This process's own staging is kept (a publish may be in flight). Best effort: a failure is logged and never holds up a launch. * feat(acp): a sign-in prompt on an ACP agent's stderr ends the start or turn signed out An agent that waits for a browser sign-in prints a link on stderr and blocks for minutes. A launch spec can now name that line (signInPrompt); the connection then closes with a typed sign-in failure through the existing process owner, so a start reads notSignedIn and a running turn fails signed out instead of settling unknown. The matched line, which carries the sign-in URL, never enters the retained stderr tail, errors or diagnostics. * Prevent sign-in URLs leaking from long stderr lines * feat(acp): an agent can enforce the permission mode itself through a session config option An optional launch-spec field names the session config option and its ask/full values. Every new or reopened session gets the value for the chat's full-access posture before it is exposed, and a refusal fails the start. With the field present Orca no longer answers permission requests for the person. No agent sets it yet. * fix(acp): reject unconfirmed permission mode during acquisition * feat(acp): an agent enforcing the permission mode itself runs the chat's own mode The launch spec maps each chat permission mode to its session option value; a start sets the value for the mode the host launches with (ask when it names none), replacing the global Agent Permissions full-access read. A mid-chat change takes effect through the host's existing restart of a child launched with another mode before the next send. * Keep ACP session acquisition within the line limit * feat(acp): open Antigravity in the Chat UI over its ACP server With the experimental chat setting on, Antigravity chats run Google's Antigravity ACP server, which Orca installs on the first chat start: a pinned 1.3.0 release whose archive and both executables are verified by hash (macOS arm64/x64, Linux x64/arm64). Each host keeps one private sign-in folder for these chats under Orca's data folder, made owner-only before every start; the server keeps its sign-in there as a file. A chat signs in with the server's Google method through the existing auth-required retry; with no saved sign-in the server's sign-in prompt ends the chat signed out. The Agent Permissions setting maps to the server's own mode, and a question the server asks shows as a question that takes one of its choices, never auto-answered. A chat reopens its session with session/resume. * fix(acp): separate Antigravity chat command and require pinned host * test(acp): assert Antigravity launch arguments across hosts * feat(acp): Antigravity chats offer Ask, Accept edits and Full access per chat Each mode maps to the server's own (default, auto_edit, yolo). No Approve for me: the server has no automatic reviewer. Accept edits gets its own description, since auto_edit approves file edit tools only. * feat(native-chat): offer host-provided chats without their CLI detected A host now marks each agentSession.agents row whose chat program Orca provides there (an ACP managed runtime with a pinned build on this host). With Chat UI on, the tab-bar picker, the empty-workspace default chat and the new-agent shortcut offer those agents beside the detected ones when the launch opens as a chat. Terminal launches still follow detection, and an older host that sends no mark keeps today's detection-only offer. * Fix CLI-free chat fallback and picker updates * Fix admission refusal reason test expectation * feat(native-chat): the host health snapshot says whether each chat's program is on the machine Antigravity's chat runs Orca's own download of Google's ACP program, not the agy CLI, so clients could not tell from CLI detection whether it can open as a chat. Each snapshot row now carries an optional chatProgram (available, installable, missing, unknown), found through the agent's own launch resolver without spawning anything, and re-derived after a managed runtime install or removal. Health state and reason are unchanged, so older clients decode the frame as before. * feat(native-chat): one renderer reading of whether an agent can open as a chat on its host Pickers asked CLI detection whether an agent can open as a chat, which is wrong for Antigravity, whose chat runs a program Orca downloads. This module answers from the host's published chat program fact, and for hosts that publish none, from the host's managed-runtime mark and install capability or else CLI detection. Facts not yet learned read as unlearned, not as no. * fix(native-chat): a declined chat opens its agent's terminal only where the CLI is installed Once a chat can be offered without its CLI, a host refusal used to fall back to a terminal that runs a CLI that is not there. The one admission boundary now reports the host's refusal instead when the workspace host's detected agents lack the CLI, for new-tab, work-item and workspace creation launches alike. A caller's own fallback, like the empty workspace's shell, still opens. * feat(native-chat): the + menu and Settings offer a chat wherever its program runs With Chat UI on and no agy CLI, Antigravity had no chat row in the + menu (or a disabled 'Not installed' one when switched on), because both read CLI detection. The menu now reads the host's chat-program answer: a chat row where the program runs or installs from the chat, no '(CLI)' row or terminal button without the CLI. A failed CLI check no longer keeps the menu from learning that answer. Settings shows an unchosen provider on when its CLI or the program Orca runs for it (downloaded or found outside Orca) is installed, and holds the switch until that is known. A saved default that opens as a chat no longer says it is not detected. * feat(native-chat): a default agent that opens as a chat starts without its CLI An empty workspace and the new-agent shortcut skipped a default agent whose CLI is not detected, even when it opens as a chat on that host (Antigravity without agy). Both now honor that default, waiting briefly for the host's chat facts when they are not known yet, while the automatic pick with no default still chooses only detected agents. Blank and the shell fallback are unchanged. * feat(native-chat): new workspaces, work items, continuations and the dashboard offer chat-only agents The new-workspace composer, work-item launches, session continuation and the dashboard launcher listed only agents whose CLI is detected, so an agent that opens as a chat without its CLI could not be picked, and an explicit pick of it was dropped. They now also offer agents that open as a chat on the workspace's host, keep such an explicit choice, and the dashboard republishes when the host's chat facts arrive. Automatic picks still choose only detected agents. * feat(native-chat): Source Control and Fix Checks accept a chosen agent that opens as a chat The Source Control action dialog, its saved auto-start, the checks panel, recovery launches and Fix Checks (before and after its workspace exists) rejected a saved or default agent whose CLI is not detected, even where it opens as a chat. They now accept it there and list it, through the shared source-control pick, while the automatic pick still chooses only detected agents. * fix(native-chat): an empty workspace does not wait on chat facts for a Claude or Codex default Claude and Codex have no program Orca downloads, so without their CLI only the host's own answer could offer them as a chat; holding the workspace empty for the host's agent list could not change that. * test(native-chat): pin the chat-program fact, cold explicit defaults and the CLI-less decline Covers the host's program lookup and its re-read after an install, older and unknown snapshot values falling back to the managed mark and install capability of the same host, an explicit default opening as a chat with CLI detection failed while automatic and blank picks stay on detected agents, kept composer and saved Source Control choices, and a declined chat reporting the refusal instead of opening a terminal for a missing CLI on both launch paths. * refactor(source-control): the action dialog's agent list lives in its own hook The dialog hook was over the file-length limit after it learned which agents open as a chat without their CLI; detection and that offer now live together in use-source-control-launchable-agents. * fix: typed test mocks and record the dialog's pre-existing reset effect The Source Control dialog's open-cycle reset effect was already on main; the changed-code gate reported it because the effect now also learns which agents open as a chat. * fix(native-chat): a declined chat refuses its terminal only when the CLI is known to be missing When a host declines a chat, Orca falls back to that agent's terminal. A chat can now be offered without its CLI, so the fallback must not open a terminal that cannot start. But a failed or still-pending CLI check is not proof the CLI is missing: treating it that way blocked a working terminal fallback (for example an OpenCode version that runs in a terminal but not as a chat). Each detection producer (local, paired server, SSH) now records the outcome of its latest attempt for the exact target, next to the IDs it already keeps. The decline check refuses the terminal only when the same host's latest attempt succeeded and did not list the CLI; pending, failed or unresolved outcomes keep the existing fallback, and a caller's own shell fallback is untouched. * fix(native-chat): every launch surface learns whether a chat opens before it decides A chat whose program runs on the host without its CLI (for example Antigravity) could be missing, greyed out or swapped for another agent depending on which surface launched it: the composer dropped an explicit pick while the host was still answering, Fix Checks and the Checks panel refused a saved chat agent, an inactive paired host was never asked about its chats, the Providers switch flashed off, and session continuation auto-picked an agent that was only offered. One lease per host, runtime and pairing now acquires the host's agent list and health stream for whoever needs it: the + menu, composers, Settings, the dashboard and its pop-out, Source Control and Checks, Fix Checks, work items, shortcuts and continuation. Actions wait for those facts within one bounded deadline (ordinary CLI detection keeps its own wait), cancel when the workspace's host is genuinely replaced, and re-read settings before launching. A saved, default or explicit choice may open as a chat without its CLI; automatic picks still come only from detected agents. Pending or unknown facts never erase a choice or flash a switch off. The dashboard's holds are reconciled by the publishers that read them, and a hold that notifies while it is being created no longer leaks a second stream holder. * fix: the new-workspace composer memoizes its launch workspace from its own fields * fix: a declined chat reads the launch host's own agent inventory; test fixtures match their types * fix: work-item launches detect before waiting on chat facts; the composer and Source Control list agents from one owner The composer card no longer holds its own chat-facts lease beside its modal's, Source Control reads agent inventory only while its dialog is open, and a work-item launch keeps the new workspace's own detection when the store has not loaded that workspace yet. * fix(native-chat): keep acquisition tied to the current host resource * fix(native-chat): verify the current acquisition before returning choices * fix(i18n): retain legacy terminal-list English entries in the runtime catalog * fix(native-chat): the dashboard republishes launch options when the active workspace's host changes Both dashboard publishers now watch the active workspace and its selected host, which own its launch options. Two QuickLaunchButton tests assert the current "couldn't list terminal agents" wording. Restores base forms and drops a duplicate workspace helper to stay inside the change budget. * test: the dashboard publisher test reads its watched state from the function it tests * fix(native-chat): dashboards watch one checked route-input view; saved Source Control discovery settles every outcome Both dashboard publishers observe and derive launch options from one exhaustive, compiler-checked view of the store slices the launch-route readers take, so a route input can no longer be missed by one list. A saved Source Control action's discovery now ends as success, cancelled or failed; only success can auto-start, and a cancelled or failed attempt reveals the editable dialog instead of launching on a replacement runtime. Restores base forms and shares one worktree workspace helper to stay inside the change budget. * style: format the runtime metadata resolver * fix: merge duplicate imports the code-quality gate rejects * test: the dashboard watch fixture seeds every route-input field * test: the dashboard watch fixture is fully typed without a cast * fix: an unknown agent scan stays unknown for Fix Checks and recovery, and a saved Checks agent keeps its message * fix: the action-first chat path asks the same missing-CLI check before opening a declined terminal; compact to the size cap * refactor: compact the chat-program changes to the size cap after merging main * Pickers list an agent that can't open here as disabled with its reason instead of hiding it The Create workspace and continuation pickers only searched the agents the caller could launch, so an enabled agent with no chat on this host (for example Antigravity when the host can't run it) lost its disabled row, while the + menu showed it. * Continuation test accepts more than one disabled subfolder row now that disabled rows are listed * Re-run CI: the code scan was cancelled across the repository * test: cover chat selection without terminal CLI * test: compact host chat program fixtures	2026-10-23 14:49:30 -07:00
Brennan Benson	29c7d5d983	fix(mobile): start AI-button agents through agent.launch, never a bare shell (#22762) ... * fix(mobile): start AI-button agents through agent.launch, never a bare shell "Fix checks with AI", "Resolve conflicts with AI", commit-failure recovery and diff review's "New Agent Session" created a terminal with no agent and typed the multi-line prompt into the shell, so each line ran as a shell command. They now call agent.launchReplay into the existing workspace with the prompt; the host picks chat or terminal from the user's default and delivers the prompt. Hosts without the launch capabilities get the buttons disabled with update copy. The agent comes from the desktop's own resolution (moved to src/shared). The replay loop and capability read are shared with the workspace-create launch. * test(mobile): repin bridged-parity tallies for the AI-button launch goldens The corpus goes from 787 to 790 goldens: five shell-path goldens are removed and eight agent.launch ones added; one lands in identical and two in result-absent-settlement. * test(mobile): re-record goldens for AI-button launches through agent.launch Repinned baseline to 514ab7f868 and re-recorded all goldens. Against the branch point: 781 header-only (baseline on all; adapterSha256 on the 48 goldens whose adapter module changed; scenarioSha256 on 3), one body moved (pr-triage-launch: createTerminal + terminal.send becomes agent.launchReplay), eight added (the new launch outcomes and their reply matrices) and five deleted (the shell-path scenarios and their matrices). * fix(mobile): show review notes' agent launch progress and failures, once "New Agent Session" left the sheet open with no progress for the whole launch (up to a minute while a terminal agent readies), so a second tap started a second agent, and a launch that never started or could not be confirmed rejected an unobserved promise, showing nothing. The sheet now closes on tap, the review screen says "Starting an agent...", one launch runs at a time, and every outcome lands in the review screen's status line. Marking notes sent now reads the screen state when the launch settles, so a note written during the wait is not dropped by the whole-list save. * test(mobile): re-record goldens for review notes' launch outcome on the review screen Repins the corpus to 6f3018576d. One golden body moves: review-create-agent-refused now fulfils with "Workspace not found" in the review screen's status line and the sheet closed, where it previously rejected an unobserved promise and left the status line empty. The other 789 goldens move only their baseline header. * test(agent-status): drop the retired PR-triage terminal send from the identity inventory The phone's AI buttons no longer create a terminal and send the prompt into it (`createTerminalAndSendPrompt` is gone); the host's agent launch delivers it. There is no terminal action consumer left in that file to pin. * fix(runtime): publish saved source-control launch recipes to paired clients settings.get is an allowlist and omitted sourceControlAi, so the phone never saw an agent saved globally for "Fix checks", "Resolve conflicts" or commit recovery and always fell back to the default agent. The host now publishes the launch actions' recipes (agent, prompt template, agent args), normalized so legacy saved defaults are already migrated. A new optional reply field: older clients ignore it, and a client talking to an older host sees none and keeps using the default agent. * fix(mobile): ask to update Orca only when the host answered without agent launch An unread or failed status read settles with no capabilities, which the AI buttons read as an old host and showed "Update Orca on your computer". The update copy now needs a status the host actually returned; an unread one keeps the buttons disabled without blaming the desktop's version. * fix(mobile): send an AI button's saved agent arguments with its launch The desktop's direct launches for "Fix checks", "Resolve conflicts" and commit recovery pass the action's saved agent arguments to agent.launch; the phone honoured the saved agent but dropped its arguments. It now sends them the same way: absent when none are saved, so the host keeps the user's configured defaults. A host that predates the field ignores it. * test(mobile): repin the RPC recording corpus after the launch recipe and availability fixes Repins to fe85e0346f. All 790 goldens move only their baseline header: no scenario saves agent arguments or reads an unreadable status, so no recorded behaviour changes. * fix(mobile): say the host status is unreadable instead of nothing when it is With the update copy now reserved for a host that answered without agent launch, an unread status left the AI buttons disabled with no explanation. They now say "Could not read this host's status. Go back and reopen it.", the words the mobile web shell already uses for the same failure; leaving the host re-reads its status. * fix(mobile): wrap an AI button's prompt in the action's saved template The desktop renders every source-control launch's prompt through the action's saved template (buildSourceControlRecoveryAgentCommandInput); the phone sent its built-in prompt as is. Now that the host publishes the recipes, the phone renders through the same shared function, refuses an empty result as the desktop does, and offers the rendered text when it could not be delivered. Review notes have no recipe and are unchanged. * test(mobile): re-record goldens for the templated AI-button prompt Repins to 7fd1555d20. One golden body moves: pr-triage-prompt-not-delivered now carries the prompt as sent (rendered through the action's template) on its prompt-not-sent result, which is what Copy prompt offers. The other 789 goldens move only their baseline header. * fix(mobile): re-read a host status that failed while the connection stayed up A status.get that timed out or was cut over settled the host's gates closed and was never asked again until the connection state changed, so the phone's AI buttons stayed disabled behind "Could not read this host's status" on a link that was working. The gate still settles closed at once, so a failed read never holds the host screen, but it now re-asks in the background with the same backoff the runtime capability probe uses, and opens once a status lands. A reply this app cannot decode is not re-asked. * test(mobile): repin the RPC recording corpus after the host status re-read The status gate change moves no recorded behavior: every golden's body is unchanged and only its baseline header moves to the new pin. * fix(mobile): show a launch's host warning as a note, not an error A launch that went ahead can carry a host warning (a structured chat ignores saved agent arguments, including the '' a template-only save writes). The AI buttons rendered it in the red error line beside a success haptic. The notice now carries it separately as secondary text, and review notes keep saying they were sent. Commit recovery also takes the synchronous in-flight lock the PR triage buttons use, so two taps before a re-render start one agent. * chore(mobile): record the host status re-read timer for React Doctor The status re-read arms one retry timer from inside its read and clears it in the effect's cleanup. React Doctor reports that self-rescheduling shape even in its minimal form, which failed both changed-lines gates. Suppressed the same way as the session startup timers. * fix(mobile): say review notes are waiting for the desktop instead of doing nothing With no live connection, New Agent Session threw from a handler whose promise the sheet drops, so the tap did nothing visible while the button stayed enabled (proven capabilities survive a drop). It now closes the sheet and shows "Waiting for desktop..." as the other AI buttons do. * fix(mobile): stop sending an AI button's saved agent arguments Whether saved arguments apply depends on the route and shell the host settles after the request (a chat ignores them and warns; malformed ones fail after admission), and the desktop sends them only when they apply. The phone cannot know that, so it now leaves them out and the agent's default arguments apply, as before this series. The saved agent and prompt template still apply. * fix(mobile): mark review notes sent through the latest save The sent marks after an agent launch went through the save callback captured at tap time, whose rollback restores the screen from that moment, so a failed save could drop notes written during the launch. It now uses the latest render's save, as it already did for the screen state. * refactor(mobile): own the host status re-read outside the effect The re-read loop lived inside the effect body, so React Doctor could not see its cleanup and needed an inline suppression plus a config allowlist entry. The loop is now a plain function that returns its stop handle, and the effect returns that handle, the same shape every caller of the runtime capability probe uses. Both suppressions are removed; behaviour is unchanged. * test(mobile): record the host descriptor from a background status re-read Pins that the status read records the host descriptor when a re-read succeeds after a failed first read, not only on the first answer. * fix(mobile): show a PR AI launch notice only under the button that launched it Fix checks and Resolve conflicts shared one error, warning and undelivered prompt, so a Fix checks launch whose prompt was not sent also offered "Copy prompt" under Resolve conflicts, copying the fix-checks prompt. Notices are now kept per button. The host availability notice stays under each disabled button, since it explains why that button cannot be tapped. * fix(mobile): say the host status is being retried instead of asking to reopen it The host status gate now re-reads a failed status in the background, so "Go back and reopen it" asked the user for a step that is no longer needed. The review sheet hint uses the same words. The mobile web shell keeps its own copy. * refactor(mobile): run the host status gate on the shared status probe The gate had its own copy of the status probe's retry loop (same delays, same cutover and backoff split, same stop on an undecodable status). The probe now takes an optional callback for each failed attempt, which the gate uses to settle closed on the first failure, and the duplicate loop and its now-unused reader are removed. Existing probe callers are unchanged. * test(mobile): repin the RPC recording corpus after merging main Re-records every golden against the merge commit and drops the three goldens whose scenarios this branch removed, which the merge had restored from main. * test(mobile): re-record the RPC goldens on the merge with main Conflicted goldens were seeded from main and re-recorded against the merged tree; every value either side recorded survives except main's terminal.send in the PR triage launch, which this branch removes. Drops three goldens main still had for scenarios this branch deleted. * feat(mobile): confirm an AI button's agent started, naming the workspace Fix checks, Resolve conflicts and commit recovery now show "Agent started in <workspace>" under the button once the host started the agent with its prompt, so a tap is no longer silent. The workspace label comes from the Source Control panel and falls back to the branch. * test(mobile): repin the recording baseline to the success-confirmation commit (header-only) * fix(mobile): name the workspace in the diff review's AI-button confirmation The diff review screen mounted the PR sidebar without a workspace label, so "Agent started in ..." under Fix checks and Resolve conflicts named the branch while the screen header named the workspace. The sidebar now requires the label so no screen can drop it, and the diff review passes the one its header shows. * test(mobile): re-record the RPC goldens on the merge with main Repins baseline to the merge commit, the last commit to touch a fenced path. Against this branch before the merge, only header fields move: baseline on every golden, and adapterSha256 on the 14 review-action goldens whose adapter main now drives through the review sheet state. No recorded body changed. * test(mobile): re-record the RPC goldens on the merge with main Repins baseline to the merge commit, the last commit to touch a fenced path. Against this branch before the merge only the baseline header moves, on every golden; no recorded body changed. * test(mobile): give the send-sheet stacking test the review controller's host status inputs The merge with main brought in #22951's stacking test, which builds the review controller without the host capability and status inputs this branch made required, so the mobile test typecheck ratchet failed. * test(mobile): re-record the RPC goldens on the merge with main Repins baseline to the merge commit 03995ae29d, the last commit to touch a fenced path. Against this branch before the merge only headers move: baseline on every golden, and adapterSha256 on the 14 goldens recorded through the terminal adapter main changed in #23080. No recorded body changed, and the merged corpus differs from main exactly as this branch did before.	2026-09-28 14:28:09 -07:00