Known issues
Limitations and bugs we know about in the current version, with what to expect when you run into them.
Each entry says what you will notice and how to work around it. For problems with a fix, see Troubleshooting.
More than one window
You get a second window from a thread's Open in new window.
- Terminal output goes to the first window
- A terminal in a second window can stay blank. Opening or reloading any window also detaches every open terminal panel, so live output stops until you open the panel again. The shells keep running.
Crashes and restarts
- A crashed core is not reported
- If the core process stops, windows aren't told, and requests wait with no error. Reload the window to start a new core. Runs that were open are marked as failed, and a message resumes them.
- Agent cleanup after a crash
- On macOS and Linux, OpenOrc records each agent process before it starts and stops leftovers at the next launch. If it can't verify one, startup stops with Agent recovery needs attention. Windows has no such record: stop leftover agents yourself before you start new work.
- Stop does not clear the queue
- Stop ends the turn, and then the next queued message is sent. Queued messages also survive a restart and are sent when OpenOrc starts, which starts the agent. Remove messages you no longer want before you stop.
- An interrupted message holds the queue
- A queued message that fails to send, or was being sent when OpenOrc closed, is not sent again on its own. It waits with Retry, and the messages behind it wait too.
Threads
- Switching back to an agent skips the other agent's work
- In a project thread, going back to an agent that already worked there resumes its own older session, without a summary of what the other agent did. Ask it to check the files. Workspace threads start fresh with a summary instead.
- A fork can know newer messages from the original
- A fork's agent continues the original thread's latest session when you send the fork its first message. If you kept working in the original before that, the fork's agent knows those newer turns too, though the fork doesn't show them.
- A fork moved to a new agent starts without the history
- If you switch a fork to an agent that never worked in the parent thread, that agent has no session to resume, and any summary it gets covers only the turns made in the fork. Tell it what it needs from the earlier conversation.
- Started threads share a folder
- A thread an agent starts with
thread_startworks in the same folder as its parent, with nothing keeping them out of each other's files. A thread can start another only while fewer than 3 of the ones it started are working, but its messages can still set more of them to work. - Schedules need the app open
- A schedule fires only while OpenOrc runs. Firings missed while it was closed collapse into one, and the next one comes a full interval later.
- Long task histories load at once
- Ordinary threads load a few turns at a time. A task's activity loads every event, which is slow for long histories.
Tasks and Git
- A task's base branch can be ignored
- When a task starts in the thread that created it, and that thread already has a worktree, the task works on that worktree's branch, even if the task records a different base branch.
- A failed setup script is not run again
- If a project's setup script fails, the worktree is kept, and the next start uses it without running the script. Run the missing steps in the thread's Terminal.
- Terminal shells outlive their thread
- Deleting a thread doesn't end its Terminal shell, and you can't open that Terminal again, so the shell runs until you quit OpenOrc. There is no limit on open shells. A running shell also blocks installing an app update: closing a Terminal panel doesn't end its shell, but End shell does.
Storage
- History does not expire
- Threads and their events grow until you delete them, with no size limit, and audit log entries are never deleted. Native agent output is the exception: its log files go after 14 days, or sooner past 512 MiB.
- Attachments are never deleted
- Files you attached stay in the data folder, even after you delete their thread.
- Staged task images are never cleared
- Images pasted into a task description are staged in the app window's browser storage, and stay there after the task is saved. Nothing removes them.
- Redaction doesn't revisit old records
- Text is redacted when it is stored. A secret saved before a rule existed stays until you delete its thread.
- Imports ignore custom CLI folders
- Importing terminal sessions reads
~/.claudeand~/.codex, even if you moved them withCLAUDE_CONFIG_DIRorCODEX_HOME. OpenCode sessions can't be imported.
Memory
- Some runs are never learned from
- A run is summarized when its agent process closes. Runs still open when you quit, idle ones included, are skipped, and summaries waiting or in progress when you quit are dropped. A failed summary isn't retried, and the app doesn't show the failure. OpenCode can't write summaries, so under Automatic · per agent its runs are skipped; choose a Codex or Claude Code subscription as the provider to include them.
- Search by meaning can stop until restart
- If the embedding worker fails, memory search uses keyword matching only until OpenOrc restarts.
Slack
- No reconnect after a restart
- Slack reconnects by itself after a network drop, but not after OpenOrc restarts. Open Settings, then Slack, and connect again.
- Questions stay in the app
- When an agent asks a question during a Slack request, Slack shows that it is waiting, but the question itself appears only in OpenOrc. Answer it there.
- Approval buttons expire
- The Allow once and Deny buttons in Slack stop working after 10 minutes, or once the connection that posted them is closed, for example when a shared relay's host disconnects. The approval still waits in OpenOrc.
- Large approvals are long
- An approval for a large edit is posted in full, over as many Slack messages as it needs. Through a shared relay, one larger than about 256 KB is refused and never reaches Slack.
- "Also send to channel" replies are ignored
- Slack marks these replies as a different kind of message, and OpenOrc doesn't take them as requests.
Windows
- OpenOrc finds agents on the
PATHit started with. After installing one, restart OpenOrc so it sees the newPATH. - Claude Code can't use Plan or Accept edits on Windows. Choose Review everything or Autonomous.
- For the same reason, Claude Code can't reply in task discussions or review pull requests on Windows, since both always run in Plan. Ask another agent instead.
- Project setup scripts run with
/bin/bash, which Windows doesn't have. - Agents update by hand. Connections shows Update instructions instead of an update button.
- The beta installers are not signed.
Linux
- OpenOrc doesn't update itself on Linux. Install each release's rpm, deb, or AppImage over the old one; your data folder stays where it is.
- Packages are x64 only and not code-signed. Check a download against the release's
SHA256SUMS.txt. - The AppImage needs FUSE 2. Install
fuse-libson Fedora orlibfuse2t64on Ubuntu, or use the rpm or deb. - Saving Slack tokens, the memory API key, or the reviewer app's key needs the Secret Service or KWallet. On a desktop Electron doesn't recognize, start OpenOrc with
--password-store=gnome-libsecret. - In a Wayland session OpenOrc runs as a native Wayland app. If the window misbehaves, start it with
--ozone-platform=x11to run through XWayland.
On Linux, OpenOrc refuses to save secrets when your system would store them as plain text, so those features stay off until a keyring is available.
Next steps
TroubleshootingFixes for the problems people run into most, from sign-in to stuck threads.Data and storageWhat OpenOrc stores on your computer, where, for how long, and what deleting removes.How OpenOrc worksThe processes OpenOrc runs, how it talks to each agent, and the path a message takes from the composer and back.
Checked against OpenOrc's source on November 9, 2026.