v0.64.0
Minor Changes
-
Crash reports from the desktop app now record what the editor's block-level
content-visibilitywas doing when a renderer died.One class of renderer crash aborts inside Chromium when a click lands on content whose ancestor has just been made unpaintable. The minidump in a bug report carries the faulting stack but nothing about the page, so triage could establish that the crash happened and not whether the editor's block wrappers were changing state at the time. That gap made the difference between a diagnosis and an informed guess.
The renderer now keeps a small crash key current as those blocks change state, and a bug report that carries a crash dump surfaces whatever the dump captured. Reports that carry no dump are unchanged, and a report from a renderer that never published a value says so explicitly rather than reading as "nothing was happening".
The reading also says whether it was current. A crash during a burst of changes is recorded differently from one that happened long after the last change, so a value in a report cannot be mistaken for evidence that something was happening at the moment of the crash when it was not.
It covers the editor's block wrappers only. The other place the app uses this CSS feature cannot report state changes at all, by design of the underlying browser event, so a crash there records nothing about that site rather than something misleading.
What is recorded is a short fixed-shape string of counters and flags. It carries no document content, no file paths, and no user data. It appears in the crash dump and, like other diagnostic decisions, in the desktop log that any bug report bundles.
Patch Changes
-
The terminal now says it is starting instead of showing an empty pane. Opening a terminal has always had a gap between the moment you ask for it and the moment the shell prints its first prompt: the project's local settings have to sync, the terminal's code has to load, a PTY host has to start, and your login shell has to run its startup files. On a cold start with a large project that gap can run for seconds, and the pane stayed completely blank for all of it, which is indistinguishable from a keystroke that did nothing. People reasonably concluded it had not worked and opened the terminal again, and again, ending up with several shells they did not want. The pane now shows a "Starting terminal" status for as long as it is waiting, and gets out of the way the moment the shell produces output. The notice fades in only if the wait is long enough to notice, so a fast terminal still opens without a flash, and it sits over the terminal area only, so the "Connect tools" and "Get Claude Code" prompts stay visible and clickable while the shell starts.
The wait itself is also shorter. Loading the terminal's code and syncing the project's settings do not depend on each other, but the code fetch only used to begin once the settings had arrived. It now starts right away, so the two happen at the same time instead of one after the other.
Downloads
| Platform | Architecture | Download |
|---|---|---|
| macOS | Apple Silicon | OpenKnowledge-arm64.dmg |
| Windows | x64 | OpenKnowledge-Setup-x64.exe |
| Windows | arm64 | OpenKnowledge-Setup-arm64.exe |
| Debian / Ubuntu | x64 | OpenKnowledge-amd64.deb |
| Debian / Ubuntu | arm64 | OpenKnowledge-arm64.deb |
| Fedora / RHEL | x64 | OpenKnowledge-x86_64.rpm |
| Fedora / RHEL | arm64 | OpenKnowledge-aarch64.rpm |