stablyai/orca

[Bug]: Qwen Code is never detected on Windows — node-launched agents need a script-path entry Summary On Windows, Orca never recognizes Qwen Code as a running agent, even though it is listed as a supported agent and launches fine. Every orchestration path that requires agent identity fails: orca orchestration worker-start --task <t> --worktree <w> --agent qwen-code → state: failed · stage: agent_readiness · lastError: timeout orca orchestration dispatch --task <t> --to <handle> --inject → runtime_error: "Cannot dispatch --inject to terminal <handle>: no recognized agent detected." The error message lists the detectable agents and qwen is in that list, so this is not a missing-agent problem — it is a detection problem specific to Windows. Environment Orca 1.4.192 (desktop, Windows) Agent runtime host (not WSL) OS Windows 11 Pro for Workstations 22631 Qwen Code 0.22.3 (official Windows installer) Node 24.14.0 The same setup works on Linux, which i

Operating system Linux Orca version v0.14.2 Details Summary When using Antigravity CLI (agy) to generate a commit message, Orca appears to pass --sandbox as the actual user prompt instead of the commit-generation prompt. Antigravity then responds with messages such as: The user request contains --sandbox Could you please clarify what you would like to do or build? Claude and Codex work correctly for commit message generation in the same Orca installation. Environment OS: Fedora Linux Orca: v0.14.2 Antigravity CLI: v1.1.12 Model: gemini-3.6-flash Effort: low Orca configuration Agent: Antigravity CLI arguments: --add-dir . --model gemini-3.6-flash --effort low --dangerously-skip-permissions Command template: {basePrompt} {stagedPatch} The issue also occurred before adding --add-dir and --dangerously-skip-permissions. Steps to reproduce Open a Git repository in Orca. Stage some changes. Select Antigravity as the Commit Message agent. Use gemini-3.6-flash with --effort low. Generate a

Operating system Windows 11 Pro 10.0.26200 (x64) Orca version 1.4.180 Details Summary On some OMP panes the sidebar agent status stays at working forever after the agent's turn has fully completed. The OMP process is alive and idle at its prompt (not exited-to-shell). The same Orca session shows other OMP panes completing correctly at the same time, so this is not a global hook outage. The distinguishing feature of every stuck pane I found is its ORCA_PANE_KEY: it is a reminted $$<base32-hash>:L$$ token instead of the normal <tabId>:<leafUuid> form. Panes with the normal UUID-form key report status fine; panes with the $$...$$ form never get a single hook event into agent-hooks/last-status.json, so the completion edge never fires and the persisted sleepingAgentSessionsByPaneKey record stays at state: working indefinitely. What is happening Orca mints a pane's identity in two ways: The normal path (makePaneKey(tabId, leafUuid) in src/shared/stable-pane-id.ts, used by pty:spawn / launch

Title Feature: Add ZCode (Z.ai / GLM-5.2) as a first-class supported agent Body Is your feature request related to a problem? Yes. ZCode (Z.ai's AI coding agent running GLM-5.2) cannot be selected as an agent in Orca. It is absent from the agent registry, so users cannot spawn it from the Orca UI, and Orca's status bar cannot report "ZCode is working". Proposed solution Add ZCode to Orca's supported agent list, alongside Claude Code / Codex / Cursor / Gemini. Concretely, one or more of: Ship a zcode-hook.sh entry under ~/.orca/agent-hooks/ mirroring the existing cursor-hook.sh / kimi-hook.sh templates (they differ only by URL path). Provide an official wrapper recipe bridging ZCode's local-subprocess hooks to Orca's HTTP hook endpoint, so lifecycle state (SessionStart / PreToolUse / Stop / …) is forwarded into Orca. Engage with Z.ai on zai-org/feedback#32 as an integration partner, since that bug currently blocks native-agent hook firing. Why ZCode is a good fit ZCode already expo

Operating system n/a (UX / product feedback) Orca version Current (reported via X after the Codex ↔ Claude Code session-resume announcement) Details Source User feedback on X (@wngli85258651) in reply to the Orca ADE post about resuming the same session across agent harnesses (Codex ↔ Claude Code): This feature is great, but I'm having a lot of trouble when I have many sessions. The names in the session list don't match the custom names I've set in OC, which is causing a lot of confusion. Problem When users maintain many agent sessions, the names shown in Orca's session list(s) often do not match the custom names they already set (in the agent harness and/or as a session/tab rename in Orca). That makes resume/history hard to scan — especially for the multi-session and cross-harness resume workflows. Expected behavior Wherever Orca lists an agent session for identification or resume, the user-set custom name should win and stay consistent across surfaces: Left agent/session sid