* Show agent status in terminal tabs
* Resolve terminal tab activity via the canonical worktree-status engine
The first pass hand-rolled resolveTerminalTabAgentActivityState, a fourth
parallel copy of the pane-iteration/freshness/title-heuristic loop that already
lives in smart-attention.ts and worktree-agent-activity-summary.ts. It diverged
from every existing surface (novel blocked>waiting split, a phantom 'interrupted'
red state the sidebar treats as idle) and re-scanned the global agentStatusByPaneKey
map per tab per store write (O(tabs*agents)).
Replace it with resolveTerminalTabActivityStatus, which reuses resolveWorktreeStatus
(the WorktreeCard resolver: freshness gate, live-PTY liveness, per-leaf title dedup,
permission>working>done priority) over a per-tab flag summary bucketed once per store
snapshot (O(tabs+agents)). Tabs now speak the same WorktreeStatus vocabulary as the
sidebar, so their live states can't disagree with the worktree card.
- Map WorktreeStatus -> AgentStateDot: working=spinner, permission=amber, done=check;
active/inactive fall through to the agent/shell identity icon.
- Parse legacy numeric pane keys too, matching the sidebar summary, so restored/
imported sessions light the tab.
- Drop the bespoke resolver + its tests; add focused coverage for the new resolver
and the leading-icon component.
Co-authored-by: Orca <help@stably.ai>
---------
Co-authored-by: Jinjing <6427696+AmethystLiang@users.noreply.github.com>
Co-authored-by: Orca <help@stably.ai>
getStaleDispatches compared space-format datetime('now') columns
(dispatched_at, last_heartbeat_at) against an ISO-Z threshold using raw
TEXT ordering. The space (0x20) sorts below 'T' (0x54) at index 10, so
every fresh same-UTC-date dispatch/heartbeat was ordered below the
threshold and wrongly flagged stale, producing a false stale warning on
each coordinator tick. Wrap both column comparisons and both bound
threshold params in julianday(), which parses the space and ISO-Z
formats as UTC for a correct numeric comparison.
Fixes#8452
(cherry picked from commit 1d40312bf2)
Co-authored-by: Neil <4138956+nwparker@users.noreply.github.com>
Co-authored-by: Orca <help@stably.ai>
* fix(codex): debounce auto-resolved approval notifications (#8387)
Codex fires its PermissionRequest hook at the human-input boundary before
the approval decision, so under 'Approve for me' the review agent approves
and Codex resumes within ~1s. The completion coordinator dispatched the OS
attention notification immediately on that 'waiting'/'blocked' hook, so the
self-resolving pause raised a false 'approval required' notification.
Debounce the Codex OS attention notification behind a 1500ms quiet window
and cancel it when a working/completion hook lands inside the window. Scoped
strictly to agentType==='codex'; every other agent's pause still notifies
immediately. The visual sidebar status is set upstream (store.setAgentStatus)
before the coordinator runs, so it stays immediate.
Co-authored-by: Orca <help@stably.ai>
* review: harden #8387 fix — protect debounce evidence + cancel on title resume
Two adversarial-review hardening fixes to the Codex attention debounce, both
preserving the fail-open contract (a genuine 'needs input' pause must always
notify):
- handleProcessInspectionResult: extend the evidence-teardown guard to also
hold while a pendingCodexAttentionTimer is armed. A transient null/shell
foreground blip (or a remote/SSH inspection that returns null foreground)
could otherwise tear down agent evidence mid-window and make the timer's
hasAgentRunEvidence guard silently drop a genuine pause banner — or fire a
false process-exit completion racing the pause. Mirrors the pendingHookDone
guard.
- recordTitleWorking: cancel the debounced attention on a genuine title-driven
resume (placed after the replay guard, so a stale post-completion title
replay never drops a still-pending genuine pause banner).
Adds 6 discriminating fake-timer tests (guard, title resume, blocked parity,
done cancels attention, dispose clears timer, second distinct pause re-arms).
Co-authored-by: Orca <help@stably.ai>
---------
Co-authored-by: Orca <help@stably.ai>
* fix(source-control): route GHES remotes to the GitHub provider for PR creation
A GitHub Enterprise Server user could not submit a PR — Orca demanded
ORCA_GITEA_TOKEN — while issue sync worked fine (#8312).
Root cause: GitHub owner/repo resolution (parseGitHubOwnerRepo) hard-rejects
any host that is not literally github.com. A GHES remote lives on a custom
host, so GitHub's forge resolveRepository returned null and provider detection
fell through the list to Gitea, whose KNOWN_NON_GITEA_HOSTS denylist cannot
enumerate arbitrary GHES domains. Issue sync was unaffected because gh
issue/pr list run with cwd=repoPath and let gh resolve the GHES host natively.
Fix mirrors GitLab self-hosted detection (getGlabKnownHosts): a new
getEnterpriseGitHubRepoSlug resolves a custom-host origin to owner/repo only
when gh is authenticated to that host — gh only ever manages GitHub/GHES
credentials, so a logged-in host is definitively GitHub. Wired into:
- forge-provider GitHub resolveRepository (fallback after github.com miss),
so detection claims GHES before Gitea is consulted;
- createGitHubPullRequest owner/repo resolution;
- isGitHubAuthenticated, which now probes the repo's real host instead of a
hardcoded --hostname github.com.
github.com repos keep the cached getRepoSlug fast path and never spawn the
extra gh auth probe.
* fix(github): host-qualify GHES gh commands and probe auth in the repo runtime
Addresses two correctness issues found in review of the #8312 fix.
1. GHES host was discarded before `gh pr create`. `--repo owner/repo` shorthand
resolves against gh's default host (usually github.com), so for a user
authed to both github.com and GHES it could target a same-named github.com
repo or fail — deterministic for SSH repos, which run gh with no cwd. Now
`createGitHubPullRequest` and the `findOpenPRByHeadBase` fallback pass a
host-qualified `HOST/owner/repo` for GHES (github.com keeps the shorthand).
Also generalize `parseCreatePRPayload`'s URL regex off github.com so a GHES
PR URL parses directly instead of limping through the list fallback.
2. GHES auth was probed on the wrong gh runtime. `getAuthenticatedGitHubHosts`
ran a global `gh auth status` with no cwd/WSL/SSH context and cached every
runtime under one "local" key, so a GHES login present only in the repo's
WSL distro was missed and the repo fell back to Gitea. Replaced with
`isGitHubHostAuthenticated`, which runs `gh auth status --hostname <host>`
with the repository's execution options (cwd/WSL distro, or SSH-local like
the create path) and caches per runtime+host — mirroring GitLab's
isGlabConfiguredForRemoteHost. This also honors GH_ENTERPRISE_TOKEN inferred
from repo context. Spawn failures stay indeterminate (uncached).
Adds createGitHubPullRequest-level tests asserting the actual gh `--repo`
arguments (create + fallback) and the WSL/SSH runtime of the auth probe.
* perf(source-control): drop redundant GHES gh auth probe in eligibility
Review follow-up. Detection only routes a GHES remote to the GitHub provider
after getEnterpriseGitHubRepoSlug has confirmed gh is authenticated to its
host, so isGitHubAuthenticated can trust a non-null slug as authenticated and
skip a second, rate-limited `gh auth status` spawn per eligibility poll.
Reaching the github.com probe now implies the remote is github.com. Tests
assert the enterprise path fires no redundant gh probe.
Once git status hit the 10,000-entry limit, the huge flag disabled every
status-refresh lane — including the push signals (repo metadata watcher,
terminal command-finished) that carry the evidence needed to clear it.
The flag only clears when a fresh non-huge status result arrives, so the
worktree deadlocked into stale Source Control and explorer badges until
an app restart.
Split the gate: evidence-free interval polling stays paused while huge
(preserving the #7983 idle-CPU fix), but push-signal refreshes now ride
the coalesced change-signal lane, so a commit made in the integrated
terminal clears the flag and resumes normal polling. A visibilitychange
listener (active only while huge pauses polling) catches up signals
dropped behind a hidden window, matching the becoming-visible catch-up
the normal lane already has.
* Allow replying to any comment in a thread, not just the root
Reply state now tracks a comment id instead of a group id, and reply composers/handlers are threaded through each comment row (root and replies alike) so any comment can receive an inline reply rather than only the thread root.
* Fix reply cancellation clearing the wrong comment's reply box
When multiple comment threads had reply boxes open, cancelling one
reply cleared replyingCommentId unconditionally, closing whichever
box was open instead of the one actually cancelled. onCancelReply now
threads through the specific commentId so cancellation only clears
state if it matches the currently open reply.
* fix(window): extend startup reveal fallback to Linux so first launch never stays hidden (#8421)
On Linux/X11, ready-to-show can never fire (GPU/driver quirks), leaving the
only BrowserWindow hidden until a second launch triggers the second-instance
reveal path. Reuse the existing bounded Windows fallback timer on Linux; the
handledInitialReadyToShow guard and headless E2E check already make the
reveal idempotent and safe.
Claude-Session: https://claude.ai/code/session_017rio4rnPiCUh8jHWxkq4xH
* docs(window): drop win32-only qualifier from tray-fallback comments
The tray-create fallback comments referenced 'createMainWindow's win32 10s
reveal fallback', but #8421 extends that reveal fallback to Linux too. Since
the tray itself is win32-only (createSystemTray no-ops off win32), naming a
platform in these comments is both stale and misleading. Drop the qualifier;
the surrounding Windows-only tray context already scopes it.
---------
Co-authored-by: kaynan <kaynan.camargo@terceiro-sky.com.br>
Co-authored-by: Brennan Benson <79079362+brennanb2025@users.noreply.github.com>
Agent-list expansion (compact "N agents" summary + per-parent lineage folds) lived in local useState on WorktreeCardAgents, so the WorktreeCard remount triggered by the child-worktrees toggle (a virtual-row key flip between item and lineage-group) and by virtualizer scroll-recycle wiped it — folding one section reset the other. Lift it into a session-scoped, LRU-bounded per-worktree module cache (useWorktreeAgentExpansionState), mirroring pr-comments-list-selection. Adds unit + integration + e2e regression tests. Reviewed for regressions and performance.
Flip the default so the front-matter banner is visible unless the user
explicitly hides it. The per-file visibility map now stores only hide
overrides (false) instead of show overrides: read defaults resolve to
true, the setter writes false / deletes on show, session persistence
preserves the real value, and hydration keeps false entries while
dropping legacy true entries back to the visible default.
Co-authored-by: Orca <help@stably.ai>
* Fix folder workspace Git status path
* fix(git): resolve folder-workspace path for all local filesystem ops
Extend the folder-workspace suffix stripping beyond git status: every
local Git subprocess cwd, the WSL-context probe, the first-work
branch/folder rename hooks, and the renderer session placeholders now
resolve the synthetic `::workspace:<uuid>` instance id to its backing
folder via splitWorktreeIdForFilesystem. Without this they would spawn
Git (or fs ops) against a nonexistent directory (ENOENT).
Co-authored-by: Orca <help@stably.ai>
* Preserve folder workspace rename instance ids
* Read folder workspace suffix from worktree id
---------
Co-authored-by: Jinjing <6427696+AmethystLiang@users.noreply.github.com>
Co-authored-by: Orca <help@stably.ai>
* feat(mobile): start a workspace from a branch, issue/PR, or Linear ticket
Unify mobile workspace creation with desktop. The "+" Create Workspace
modal now has a primary "Start from" field that opens a tabbed search
drawer (Branch · GitHub · GitLab · Linear), letting a user start a
workspace from an existing/new git branch, a GitHub issue/PR, a GitLab
issue/MR, or a Linear ticket — in addition to the default blank workspace.
No new backend is required: the search RPCs (github.listWorkItems,
gitlab.listWorkItems, linear.searchIssues/listIssues, repo.searchRefs) and
the worktree.create linked-item params were already used by the mobile
Tasks screen. This surfaces them in the create flow, reusing the existing
pure modules (buildTaskWorkspaceCreateParams, shouldResolveHostedReviewStartPoint,
filterAvailableTaskProviders).
Details:
- New pure modules: workspace-source-selection, use-workspace-source-search,
source-workspace-create, worktree-create-retry, blank-workspace-create
(the blank/retry path extracted from the modal for reuse + line budget).
- New UI: WorkspaceSourcePickerDrawer (+ row) and SetupHookTrustDrawer
(extracted from the modal).
- Older paired desktops (missing the mobile.tasks.v1 capability) degrade to
Branch + Blank only; GitLab/Linear tabs appear only when available.
- GitHub/GitLab sources pin their repo; switching repos resets the source.
PR/MR sources resolve their base branch at create time; SSH repos gate
search until connected (Linear search is repo/SSH-independent).
* fix(mobile): hydrate settings/trust before availability probes settle
Review fixes for #7985: setTrustedOrcaHooks/setRuntimeSettings no longer
wait on status.get/preflight.check/linear.status (a first-open
preflight.check can take seconds, widening the spurious setup-trust
re-prompt window). Also adds param-parity tests for createBlankWorkspace
and a GitLab MR base-resolve test.
* feat(mobile): match desktop's Smart source picker exactly
Rework the mobile create-workspace source picker to be a faithful port of
desktop's Smart picker instead of the earlier divergent "Start from" drawer.
The mobile field is now the workspace-name input AND the source search, with the
exact desktop tabs — Smart · GitHub · Linear · GitLab · Branch · Name. "Smart"
fans out across GitHub + GitLab + Linear + branches, prepends a "Use '<name>'"
row, and resolves pasted URLs / #123 / STA-42 to exact items (with a cross-repo
switch prompt). Selecting a source shows a pill and moves the editable name into
Advanced. The invented "Blank workspace" concept is removed — the neutral state
is just a typed/empty name (blank submit still yields a creature name).
DRY: the pure desktop logic (smart-workspace-source-results, -command-value,
github-links, gitlab-links, work-item-link-query-bounds, github-work-item-identity)
moves to src/shared/new-workspace/ with re-export shims at the old renderer paths,
so both renderer and mobile share one implementation. composer-branch-selection
and workspace-name were already shared and are reused directly.
Two read-only lookup RPCs are allowlisted for mobile so pasted GitLab URLs and
cross-repo GitHub URLs resolve to exact items (github.workItemByOwnerRepo,
gitlab.workItemByPath).
New mobile modules are split for max-lines: use-mobile-composer-source (selection
state + desktop-parity handlers, PR/MR base resolve), use-smart-workspace-source
+ smart-source-fan-out/-search-requests/-paste-intent (RPC orchestration),
composer-linked-work-item / work-item-lookup-text / mobile-smart-source-modes
(pure logic), and SmartWorkspaceSourceField/Drawer/Row + SmartWorkspaceAdvancedFields.
Replaces WorkspaceSourcePickerDrawer/Row, workspace-source-selection,
use-workspace-source-search, and MobileWorkspaceNameInput.
Reviewed by three adversarial agents + re-reviewed after fixes: GitHub search now
returns issues AND PRs (not issues-only), Linear defaults to assigned, create-branch
preserves slashy names, cross-repo PR base resolves against the item's own repo,
displayName is suppressed for user-edited names, and the smart-mode GitHub fan-out
respects availability. tsc/oxlint/max-lines-ratchet clean; 1328 mobile tests pass.
* fix(mobile): keep smart source drawer fully visible
* refactor: share workspace creation behavior across clients
* fix: address workspace creation review findings
---------
Co-authored-by: Brennan Benson <brennanbenson@Brennans-MacBook-Pro.local>
Reply state now tracks a comment id instead of a group id, and reply composers/handlers are threaded through each comment row (root and replies alike) so any comment can receive an inline reply rather than only the thread root.
* fix(terminal): stop stale PTY resize after worktree reveal
The visibility-resume size readback captures xterm's pre-reveal grid as
its resize target while the applied-size read is in flight. A reveal fit
or snapshot-restore resize can change the grid mid-flight without
queuing a newer request, so the resolved callback "repaired" the PTY
back to the pre-reveal grid — an idle TUI (Claude Code) then redraws
for the wrong grid until a manual resize (refs #7951, #7240).
Instrumented traces show the stale capture on every reveal; correctness
relied on the read winning FIFO against the fit's resize, which busy
daemons and SSH/relay round-trips lose.
Re-measure xterm at resolve time and re-run against the fresh grid
instead of forwarding a stale target. Adds an e2e seam that delays the
readback dispatch to reproduce the losing ordering, unit repros that
fail without the guard, and a hidden-resize/reveal-cycle e2e spec.
* test(terminal): cover single-flight convergence under an oscillating grid
* docs(e2e): note the WINCH bar is illustrative, not a Windows ground truth
The reveal repro asserts on pty:getSize convergence; the bottom-bar TUI
only makes the pane WINCH-reactive. Record that a long-lived process can
miss Node's stdout 'resize' event under Windows ConPTY even when the OS
PTY was resized, so future readers don't add a flaky bar-content check.
Brennan Benson
moseoh
github-actions[bot]
Jinwoo HongandOrca
