Install & first launch
macOS — Apple Silicon: …_aarch64.dmg · Intel: …_x64.dmg (requires macOS 13+)
- Developer ID-signed and notarized. Open the DMG and drag Open Science into Applications.
- When you use an existing project in place, allow access to its folder if macOS asks.
Windows — …_x64-setup.exe (start here) · …_x64_en-US.msi (IT-managed deployment only)
- SmartScreen shows "Windows protected your PC" → More info → Run anyway.
- Upgrading: choose "Install over it, keeping my data". Removing the old version first is only for repairing a failed upgrade.
- Uninstalling: leave "Also delete my sessions, run history and settings" unchecked unless you mean it — it erases
%APPDATA%\com.ai4s.workbench. - Pick one format and stay on it. Installing the
.exeover an.msiinstall (or the reverse) registers the app twice; uninstall the old one from Settings → Apps first.
Linux — .deb / .rpm
sudo apt install ./…_amd64.deborsudo rpm -i …x86_64.rpm
No in-app auto-update — download new versions from this Releases page. (The
.app.tar.gzassets are build artifacts, not an update channel.)
0.5.1 — repair work
Almost everything here is a fix, and almost every fix started as something one
of you reported. Two of them were bad: a conversation that could stop accepting
messages for good, and a window that flickered every time the app opened. Both
are gone. Thank you for the reports, the screenshots and the patience — several
of these were found by people who had already switched to something else and
took the time to write the issue anyway.
A conversation could stop accepting messages, permanently (#114)
If you had Settings → General → Review switched on, a background review
would finish and attach its findings to the conversation — and from the next
message onward, every turn in that conversation failed with Invalid prompt: The messages do not match the ModelMessage[] schema. It never recovered. Retrying
reproduced it exactly, restarting the app did not help, and the conversation was
effectively lost.
The cause was ours. When a review finished, its findings were saved onto the
last reply with a small marker attached. The agent runtime passes such markers
through to the model, which requires them in a particular nested shape, and ours
was one level too flat — so the model's API rejected the whole conversation
before the request ever left your machine. That is why nothing you could do made
any difference.
Three things ship for it:
- The marker now has the right shape, so new conversations cannot be damaged
this way. - Conversations already damaged are repaired as they are sent. Nothing is
rewritten on disk. A conversation that has been stuck since an earlier version
should simply continue when you open it in 0.5.1. - If a conversation is ever broken in a way we do not recognise, the error
now says plainly that retrying cannot help, names the message responsible when
it can, and offers to roll back to just before it — telling you first how many
messages that discards.
Our earlier explanation of this bug, both in the app and on the issue, blamed an
interrupted tool call. That was wrong, and it is gone. Auto-review is off by
default and is safe to switch on again.
The app no longer flickers on launch
Every start briefly flashed the "no runtime" card, a red error banner and the
status badge, several times a second, while the agent runtime was still coming
up. Nothing was actually wrong — the app was simply reporting each connection
attempt as a failure before the runtime had finished starting. A slow first
launch now shows one calm message explaining the wait instead.
Using the app from a browser, or on a machine with no screen (#119)
- Adding a custom model provider from the web client returned 403. It now
works. - On a headless machine there was no way to add one at all:
osd auth setcould
only write a key, never the endpoint and models a custom provider needs. It
now takes--base-url,--modelsand--npm, and warns you when a
combination would be silently ignored. - Settings pages that the web sidebar only hid stayed reachable by typing the
URL, and led to controls the gateway cannot honour. They are properly closed
now, and say where the setting actually lives.
A bad configuration file no longer stops the app from starting (#118)
A malformed opencode.jsonc could leave the app unable to start, with a
connection loop and no way in. Config writes are now disciplined, and a file
that cannot be parsed is recovered rather than fatal.
Quota errors say whose quota it is (#117)
"Free usage exceeded" named no provider, so it read as this app having a quota
and running out of it. The message now names the account the allowance belongs
to, and points at where to switch model or add a key.
Watching a turn work
A running turn now shows what it is doing rather than only that it is busy, and
a subagent can be opened from the transcript while it is still running, instead
of only after it finishes.
osd, on servers
The bundled osd command now survives a shell that never logs in — the usual
case over SSH and in containers — and shuts down together with the app instead
of outliving it and holding the port.
Thank you
- @SIITW for the original #114 report — thorough enough that it was still
the best description of the bug two weeks later — and for confirming the
first fix. - @wangj1758 for reopening #114 when it came back, and for the observation
that finally cracked it: leave the conversation idle, wait for a Review to
appear, and the next message fails. That one sentence is what turned this
from a mystery into a one-line fix. - @HaoyanZhang123 for #118 and for confirming #114 independently,
@yiqinggou for #117, and @zigerZZZ for #119. - @284531733 for confirming #114 as well.
If you hit something, please open an issue — this release is almost entirely
made of them.