All documentation

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_start works 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 ~/.claude and ~/.codex, even if you moved them with CLAUDE_CONFIG_DIR or CODEX_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 PATH it started with. After installing one, restart OpenOrc so it sees the new PATH.
  • 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-libs on Fedora or libfuse2t64 on 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=x11 to 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

Checked against OpenOrc's source on November 9, 2026.