[nwparker]

	Files	Added	Deleted	Net
Test	2	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​37	$\color{#cf222e}{\Huge{\mathbf{−}}}$​2	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​35
Prod	1	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​3	$\color{#cf222e}{\Huge{\mathbf{−}}}$​15	$\color{#cf222e}{\Huge{\mathbf{−}}}$​12

ELI5

You start Claude with your own flags (say --dangerously-skip-permissions --model haiku), sleep the workspace, and wake it. The woken agent runs with your flags. But if Orca restarts after that wake (an update, a reboot, a crash), the restored agent comes back as a bare claude --resume <id>: on the default model, and without bypass permissions. Orca erased the pane's saved flags at the moment it woke.

This takes the smallest part of #31756 by @Jinwoo-H (STA-11575). Their two commits are kept as written, plus one test commit.

Root cause

When a pane wakes in place, it registers its launch config (registry entry, keyed by launch token) and then consumes the sleeping record it resumed from. The consume step, clearSleepingAgentSessionsByPaneKey (agent-status-runtime.ts), deleted the registry entry too, so the config the pane had just registered was gone. A moment later the agent's first hook arrives carrying the launch token (Claude sends SessionStart at startup). recordAgentProviderSession then looks for a matching registry entry, finds none, and writes the pane's live record with no launchConfig. That live record is the one persisted and used for cold restore.

Why main hides this until a restart: since #31564, a manual sleep is captured in main from the live PTY's launchConfig (worktree-sleep-resume-recording.ts), so sleep→wake→sleep→wake keeps the flags. The renderer's live record is still the cold-restore source after a quit, and it is the record that loses them.

What changed

• clearSleepingAgentSessionsByPaneKey clears only sleeping records. Launch configs still retire with the pane (removeAgentStatus*, dropAgentStatus*, dropHibernatedAgentStatusPane, retireAgentPaneAuthority, worktree-level clears). A stale entry can't attach to a different launch, because registryEntryMatchesStatus requires the launch token and provider session to match. fix(agent-status): keep saved launch flags when a woken agent sleeps again #31756 has the full audit of every clearSleepingAgentSession* caller.
• Regression test: a woken pane whose first token-bearing hook arrives after the consume keeps launchConfig on its live record. It fails on main and passes with the fix.

Left out of #31756 on purpose: the resumedProviderSession capture-only field (its commits 3–4). It covered renderer sleep capture (captureSleepingAgentSessionsByWorktree) for a Codex pane that sleeps before its first prompt. Production no longer calls that capture, because main captures sleeps now. Every Codex hook carries the launch token (hook-envelope.ts). Codex runs SessionStart only inside the first turn (codex-rs/core/src/session/turn.rs:341 → hook_runtime.rs:129), and until then the renderer has no provider session for the pane to capture anyway. If the orchestrator wants that path covered too, it can be a follow-up.

How verified

Real Orca dev build (background, isolated HOME / CLAUDE_CONFIG_DIR / profile), real Claude Code 2.1.310, flags --dangerously-skip-permissions --model haiku:

Step	origin/main	this branch
launch	claude --dangerously-skip-permissions --model haiku	same
sleep → wake (×2–4)	... --model haiku --resume <id>	same
renderer live record after wake	launchConfig: null	--dangerously-skip-permissions --model haiku
registry after wake	{}	entry kept with the wake's token
quit → daemon gone → relaunch (cold restore)	claude --resume <id>: Opus default, "auto mode on"	claude --dangerously-skip-permissions --model haiku --resume <id>: Haiku, "bypass permissions on"

Argv was read from the process table, and each screen was checked with a CDP screenshot.

• pnpm tc:web, pnpm run check:code-quality:changed: pass
• pnpm test src/renderer/src/store/slices/agent-status src/renderer/src/components/terminal-pane/pty-connection ...: 97 files, 1352 tests pass, plus the terminal-pane suites that touch the registry.

Risk

Low. 3 files, about 40 lines. The only behavior change is that a registry entry outlives the consume of its pane's sleeping record. Pane retirement still removes it, and token/identity matching gates any reuse. Remote, SSH, mobile, and folder workspaces use the same renderer store path, with no platform-specific code.

Co-authored-by: Jinwoo Hong 73622457+Jinwoo-H@users.noreply.github.com

[coderabbitai]

Walkthrough

The sleeping-session clear operation now removes matching entries only from the sleeping-session map. It leaves the launch-config map unchanged. Tests verify that clearing multiple records preserves the original launch-config map and that recording a provider session after a pane wakes creates a sleeping record with its registered launch configuration.

Priority: Pending latest changes

Merge Risk: Moderate · up to 10894

A resumed session can inherit another session’s model or permission flags; bind the retained configuration to the consumed provider session before merging.

Pre-merge checks: 4 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 3 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 4 passed

Check name	Status	Explanation
Title check		The title clearly identifies the main change: preserving launch flags on a woken agent so a restart restores them.
Description check		The description is detailed and on topic. It explains the root cause, implementation, scope, regression test, manual verification, automated test results, and risk. It references issue #31756, althoug…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Description check

Explanation

The description is detailed and on topic. It explains the root cause, implementation, scope, regression test, manual verification, automated test results, and risk. It references issue #31756, although it does not reproduce every template heading or checklist item.

Finishing Touches: 💡 1

📝 Generate docstrings: 💡

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to GitHub limitations.

⚠️ Outside diff range comments (1)

Minor · Retain the consumed provider session in the launch-config… · agent-status-runtime.ts:187-216

src/renderer/src/store/slices/agent-status-runtime.ts:187-216
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

Retain the consumed provider session in the launch-config identity.

clearSleepingAgentSessionsByPaneKey removes the sleeping record but leaves a token-only registry entry. registryEntryMatchesStatus returns true for that entry after the launch-token check, before it can compare existingProviderSession. A Pi session_start resume hook can provide a different providerSession under the same launch token, so recordAgentProviderSession copies the old launch flags into the new session’s sleeping record. Cold restore can then relaunch that session with stale model or permission flags.

When consuming the sleeping record, copy its providerSession into the retained registry entry’s identity before deleting the record. The existing provider-session comparison will then preserve flags for the original session and reject registry reuse for a different session.

Suggested fix

     set((s) => {
       let nextSleeping = s.sleepingAgentSessionsByPaneKey
+      let nextLaunchConfigs = s.agentLaunchConfigByPaneKey
       for (const paneKey of uniquePaneKeys) {
+        const sleepingRecord = s.sleepingAgentSessionsByPaneKey[paneKey]
         if (paneKey in nextSleeping) {
           if (nextSleeping === s.sleepingAgentSessionsByPaneKey) {
             nextSleeping = { ...nextSleeping }
           }
           delete nextSleeping[paneKey]
+          const registryEntry = s.agentLaunchConfigByPaneKey[paneKey]
+          if (registryEntry && sleepingRecord) {
+            if (nextLaunchConfigs === s.agentLaunchConfigByPaneKey) {
+              nextLaunchConfigs = { ...nextLaunchConfigs }
+            }
+            nextLaunchConfigs[paneKey] = {
+              ...registryEntry,
+              identity: {
+                ...registryEntry.identity,
+                providerSession: sleepingRecord.providerSession
+              }
+            }
+          }
         }
       }
-      if (nextSleeping === s.sleepingAgentSessionsByPaneKey) {
+      if (
+        nextSleeping === s.sleepingAgentSessionsByPaneKey &&
+        nextLaunchConfigs === s.agentLaunchConfigByPaneKey
+      ) {
         return s
       }
-      return { sleepingAgentSessionsByPaneKey: nextSleeping }
+      return {
+        sleepingAgentSessionsByPaneKey: nextSleeping,
+        agentLaunchConfigByPaneKey: nextLaunchConfigs
+      }
     })

---

Review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Repository UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: b587feaf-2520-4f29-9f7a-e1affd00a4db

Commits

Reviewing files that changed from the base of the PR and between 51dcef8 and 10894d9.

Files selected for processing: 3

• src/renderer/src/store/slices/agent-status-provider-session.test.ts
• src/renderer/src/store/slices/agent-status-quit-capture.test.ts
• src/renderer/src/store/slices/agent-status-runtime.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 0 remain after this review.