[Bug]: "Send notes to agent" from a Markdown note fails with "The selected terminal is not a recognized agent session. (no-agent)" #24286

Activity

1. AmethystLiang

   added

   bugSomething isn't workingSomething isn't working

   on Oct 1, 2026
2. bashrusakh commented on Oct 3, 2026

   

   bashrusakh

   on Oct 3, 2026

   Last edited by bashrusakh

   More actions

   Took this into work. Opened #25010 to fix it.

   Root cause: the "Send notes to" menu listed a pane whenever its OSC title read as an agent, but the runtime's send guard independently verifies agent presence before typing. A pane whose only title evidence was a lone quarter-circle spinner (◐/◑/◓/…) was offered by the menu yet refused by the guard, because the runtime treats a bare spinner frame as generic progress rather than identity (STA-4028). That is the offer-then-refuse that surfaced as The selected terminal is not a recognized agent session. (no-agent).

   Fix (#25010): the menu now rejects a title whose only agent evidence is a lone quarter-circle frame, reusing the same shared predicate the runtime already uses. Titles that also name their agent (◐ Claude Code) or use a braille spinner remain eligible. The no-agent toast now tells the user to start or resume an agent and try again.

   On the second question: a new session is not needed for every note when an agent is already running; that session can receive repeated notes. If no running or resumable agent exists, starting one may create a new session. The updated toast makes no blanket claim either way.

   If you can share which agent was running (Claude Code / Codex / other) and whether the terminal was a restored session, that would help confirm your exact case.
3. bashrusakh

   added 2 commits that reference this issue on Oct 3, 2026

   fix(notes): remove unsupported session claim from no-agent toast (sta…

   ...

   26dead5

   fix(notes): localize no-agent send messages (stablyai#24286)

   e5bf316
4. Viy1204 commented on Oct 8, 2026

   

   Viy1204

   on Oct 8, 2026

   More actions

   Posting from my own account for clarity: I'm the person this report came from, and everything below was measured on my own install.

   Answering the two questions: the agent was Antigravity (agy). It was originally hand-typed into a plain pwsh terminal, not launched by Orca and not a restored session. But I re-tested since and that turns out not to be the variable — see below.

   Orca 1.4.217 on Windows, agy at %LOCALAPPDATA%\agy\bin\agy.exe, Antigravity CLI 1.2.13.

   Three things I can show, none of which matches the lone-spinner path.

   1. The title is a shell path, not a spinner. orca terminal show on my pane:

      "title": "C:\\Program Files\\PowerShell\\7\\pwsh.exe"
      "agentIdentity": "antigravity"
      

      and orca terminal read ends on a bare > with no TUI chrome and no spinner anywhere. This is not a degraded state — I started a second Antigravity from scratch and got the identical pwsh.exe title and the identical bare >. Antigravity CLI 1.2.13 appears to never set an OSC title at all. For contrast, the Codex pane in the same worktree reports "title": "Codex ready" and works.

   2. It is not about how the agent was started. I created a fresh agent with Orca's own documented path (orca terminal create --worktree active --command "agy"). Result:

      "title": "C:\\Program Files\\PowerShell\\7\\pwsh.exe"
      "agentIdentity": "antigravity"
      "agentWait": null
      

      orca terminal wait --for tui-idle timed out, and agent-hooks\last-status.json gained no new entry for the new pane. So a brand-new Antigravity launched by Orca itself is in the same state as my hand-started one.

   3. The two Orca-side channels disagree. The identity channel works — the foreground-process check against detectCmd: "agy" is what produces agentIdentity: "antigravity". The status channel does not: the hook reported Stop / state: "done" once on 2026-09-30 16:40 for my original pane and nothing since, and never at all for the fresh one. Since the send pre-check is

      let { agentStatus } = await rpc(`terminal.agentStatus`, { terminal })
      return agentStatus.isRunningAgent ? ... : { status: 'no-agent' }
      

      no-agent is exactly isRunningAgent === false, and that is derived from the channel that isn't reporting. Meanwhile the menu still offers the pane, because Z() also builds targets from registered agent sessions (and pe() returns null for a pwsh.exe title, so the title path isn't what's offering it).

   So for Antigravity this looks like a half-wired integration rather than the offer-then-refuse STA-4028 describes: Orca can tell what agent it is, but can't tell whether it is currently able to accept input, so it offers the target and then refuses on the same pane.

   That also means #25010 is a no-op here. It narrows renderer-side title eligibility, but this pane isn't offered via the title path, and the refusal comes from terminal.agentStatus, which the PR doesn't touch. Worst case it turns a visible error into a target that silently isn't there.

   Caveats, so I'm not overclaiming: I could not read isRunningAgent directly (orca doesn't expose terminal.agentStatus), and my fresh instance came up saying "not signed in" and never reached tui-idle, so I can't fully separate "the hook never fires for Antigravity" from "the hook only fires once a turn completes and my original pane's single Stop is simply too old to count". My original pane is the weaker half of that pair — it was signed in and ran many turns, and still only ever reported one event.

   Two things that would help me narrow it, if you're interested:

   • Does terminal.agentStatus have a notion of hook-status freshness, or should a done state from a previous turn keep counting as a running agent? Mine has been idle 8 days with the process alive.
   • Should the session path in Z() offer a target whose title resolves to a shell, given the title path already declines to? That combination looks like the actual offer-then-refuse pair for Antigravity.
5. bashrusakh commented on Oct 8, 2026

   

   bashrusakh

   on Oct 8, 2026

   Last edited by bashrusakh

   More actions

   Thanks for the detailed re-test — the structural reading is correct, and it is now tracked separately: #26568. The offer path (deriveTerminalAgentSendTargets over the renderer's status store) and the send pre-check (terminal.agentStatus → isRunningAgent) are independent derivations of "is an agent alive here", and nothing keeps them consistent. Neither #25010 nor #25513 touches either of them — your "no-op for my pane" observation stands. (The one part of those PRs that does reach your case is the reworded no-agent toast.)

   A few concrete answers:

   1. Your tui-idle timeout is the already-fixed Antigravity workers fail at agent_readiness: tui-idle reads only the output stream for Antigravity panes #24486 symptom. At v1.4.217 the readiness poll only consulted the rendered screen for Codex panes; fix(runtime): read Antigravity, Cline and Prime Agent readiness from the live screen #24222 (merged Oct 1) and refactor(runtime): read four agents' readiness from JSON rule files through one engine #24348 (Oct 2) made it consult the screen rules for Antigravity too, first released in v1.4.220. v1.4.217 (Sep 29) predates both — please update to ≥ v1.4.220 and re-test; the "no new entry in last-status.json / wait never ends" half may disappear without any further fix.

   2. Freshness already has a coded answer. AGENT_STATUS_STALE_AFTER_MS = 30 * 60 * 1000 (src/shared/agent-status-freshness.ts) — a hook row older than 30 minutes is excluded. So your 8-day-old Stop intentionally does not count as a running agent. Whether an idle-but-alive pane should count is a policy question, and it (plus the session-path offer eligibility you asked about) is now question 1/2 in [Bug]: Send-notes offer path and terminal.agentStatus pre-check derive agent aliveness independently (structural offer-then-refuse) #26568.

   3. Whether agy ever writes fresh hook rows on Windows is the remaining unknown — if a freshly launched Antigravity pane never produces a hook entry even on a current version, that points at the Windows hook installation problem in [Bug]: Windows: Antigravity (agy) sessions missing from sidebar — orca-status bundle wiped from ~/.gemini/config/hooks.json and never reinstalled #17672 rather than at the send menu. That would confirm your "half-wired integration" framing: identity comes from the foreground-process check, aliveness from a channel that never fires.

   Issue #24286 itself keeps tracking the spinner-title lane (addressed by #25513, which is still open — not merged yet); your case lives in #26568 now.