Skip to content

Resume: follow-ups for #6 and #30 after the 2026-10-22 sync #41

Open

Description

@kiwidream

Smaller resume follow-ups left by the 2026-10-22 sync (#38). Each item says what the sync did and what is still open.

#6, auto-resume after a host restart

#30, host resume of a re-created pane

  • Managed-orcad SSH hosts. The fork's SSH skip tests workspace.connectionId, which a managed-orcad catalog sets to null. So a fork-built orcad now runs the host resume on managed SSH hosts. This is inferred from the code and untested; decide whether that is wanted.
  • Automatic-restore pauses. The no-record fallback declares no restore intent, so it ignores an operator, unclean-death or pressure pause, while upstream's record resumes wait. This keeps the "daemon replaced" journey working. Decide whether it should wait too.
  • Native-chat adoption. The terminal-loss remnant drops its process presence, so upstream's writer check (Refuse chat resume until terminal writers have exited stablyai/orca#29242) refuses "Resume in New Native Chat" and chat adoption until the pane is re-created. A tested alternative is to keep the presence marked ended: it passes the fork's 117 related tests. Its cost is that it marks a process ended that was never proven ended, so later hooks from that process are dropped. The alternative, in server-retained-identity.ts:
    -  const { agentPresence: _agentPresence, ...terminalIdentity } = resumeIdentity
    +  const { agentPresence, ...terminalIdentity } = resumeIdentity
       return {
         ...terminalIdentity,
    +    ...(agentPresence ? { agentPresence: { ...agentPresence, ended: true as const } } : {}),
         providerSessionOnly: true,
  • Layout-owner build. In upstream's dark layout-owner build, the fallback does not resume while a window is attached; main-written records cover that case. Recheck when upstream switches the build on.
  • Legacy records and [Bug]: Creating a Claude tab from mobile spawns it on the desktop, then reaps it ~10s later — mobile tab creation broken stablyai/orca#7587. The fresh-launch suppression also applies to panes with an originless legacy record. Narrowing it is a one-token change.

Hardening nits

  • resolvePaneScopedTuiAgent reads …?.identity.agentType without guarding identity. Upstream guards its sibling reads.
  • When upstream does its P5b-2 retyping, move fix(session): treat an unprovable connectionId as no host, not as ssh #5's folderWorkspaces read in workspace-session-host-persistence.ts to the typed selector and drop the raised workspace-record-read baseline.

Activity

  1. kiwidream commented on Oct 23, 2026

    @kiwidream
    Author

    From the 2026-10-23 sync (#50): upstream stablyai#31718 adds an in-memory resume claim, agentSessionResumeClaims in agent-session-resume-ownership.ts. Upstream's pane-owned resume and its new targeted resume (resumeAgentSessionInWorkspace) both take it, so one session cannot be resumed twice while a spawn is in flight. Upstream stablyai#32120 ends a claim when the hook store reports the session.

    The fork's hook-store resume (#30, host-pane-agent-resume-start.ts) does not take that claim. It runs only for a pane with no sleeping record (resolvePaneOwnedResumeStartup returning undefined). Upstream returns {} while another resumer holds a claim, so the fork never resumes over upstream's pane-owned path. A targeted resume could still race it. That needs the same provider session to be recorded in one pane and named by the hook store in another pane that has no record. Today the only caller of the targeted resume is the external-conversation reopen (external-conversation-reopen.ts), which is off by default behind experimentalConnectors.

    The sync changed none of this. Worth deciding together with #42: have startHostPaneAgentResume take agentSessionResumeClaims for the session it resumes, or accept the race while connectors stay experimental.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions