[Bug]: Send-notes offer path and terminal.agentStatus pre-check derive agent aliveness independently (structural offer-then-refuse) #26568

Activity

1. bashrusakh commented on Oct 8, 2026

   

   bashrusakh

   on Oct 8, 2026

   Author

   More actions

   Proposed fix direction: make Send Notes eligibility runtime-authoritative

   I would fix this at the Send Notes authority boundary, rather than by adding another renderer-side heuristic or by attempting a repo-wide unification of all agent-presence semantics.

   The core problem is not a single missing condition. Today, two independent paths answer effectively the same product question:

   Renderer:
   agentStatusByPaneKey + title + PTY
       -> target is offered as eligible
   
   Runtime:
   hook status + title + foreground process + presence rules
       -> terminal.agentStatus
       -> send is allowed or refused
   

   As long as those remain independent derivations, they can drift. Fixing individual mismatches in the renderer only moves the divergence point.

   Proposed authority model

   For Send Notes, the runtime should be the single authority for:

   “Can Orca safely send input to this terminal as an agent right now?”

   The renderer may still perform candidate discovery, but it should not independently make the final eligible decision.

   Conceptually:

   Renderer discovers candidate terminal
                 |
                 v
         terminal.agentStatus
                 |
                 v
           Runtime authority
                 |
           +-----+------+
           |            |
        eligible      disabled
                       |
             no-agent / permission / unavailable
   

   The final send-time guard should remain in place and call the same runtime authority again, because terminal state may change between opening the menu and clicking Send.

   Suggested separation of responsibilities

   deriveTerminalAgentSendTargets should answer:

   “Which terminal panes are plausible Send Notes candidates?”

   It should not be the final authority for:

   “Is this terminal currently safe and valid to send to?”

   The latter should come from the runtime.

   That would turn the current flow from:

   renderer heuristic -> eligible
   
   runtime heuristic  -> no-agent
   

   into:

   renderer discovery
          |
          v
   runtime readiness -> menu eligibility
          |
          v
   runtime readiness -> final send guard
   

   Why not copy more runtime checks into the renderer?

   That would preserve the underlying problem.

   The runtime presence decision can depend on evidence such as:

   • fresh hook state
   • terminal title
   • foreground process
   • launch identity
   • ready-prompt evidence
   • agent-specific presence rules

   The renderer does not necessarily have all of that evidence, and duplicating the runtime rules would create another implementation that must remain synchronized indefinitely.

   A local patch such as adding the current shell-title rejection to the renderer may fix one reproduction while leaving the same structural failure mode available through another evidence combination.

   Why not introduce one global isAgentAlive() abstraction for all Orca consumers?

   That seems broader than necessary for this issue.

   Different consumers legitimately ask different questions:

   Sidebar:
   “Is there agent activity worth displaying?”
   
   Worktree status:
   “What status should be shown?”
   
   Permission handling:
   “Is the agent waiting for user action?”
   
   Send Notes:
   “Is it safe to submit input to this terminal now?”
   

   Those do not necessarily need identical evidence or policy.

   So I would avoid turning #26568 into a global agent-state refactor. The narrower invariant needed here is:

   All Send Notes decisions that authorize input should share the same runtime authority.

   Concrete invariant

   After the fix, this should not be possible purely because the renderer and runtime interpreted agent presence differently:

   Send Notes menu: eligible
   Send pre-check:   no-agent
   

   A target may still become invalid between discovery and send because state changed, which is why the final guard remains necessary. But the menu and the send guard should not disagree because they use different definitions of agent presence.

   Scope

   This is intentionally between two extremes:

   • not a one-off Antigravity-specific fix;
   • not a repo-wide agent-state redesign.

   The proposed scope is:

   Make Send Notes terminal eligibility runtime-authoritative, while keeping renderer-side logic for discovery and presentation only.

   That removes the structural offer-then-refuse class without weakening the existing fail-closed send guard.
2. AmethystLiang commented on Oct 8, 2026

   

   AmethystLiang

   on Oct 8, 2026

   Contributor

   More actions

   Thanks for reporting. Looking into it
3. AmethystLiang

   assigned

   Jinwoo-H

   on Oct 8, 2026