v2.9.2

Fixed

• Closing the terminal that runs gno serve or gno daemon now shuts it down cleanly, as Ctrl-C or --stop do. It used to be killed on the spot, leaving work cut off and a stale lock note behind until the next start. A server started with nohup still keeps running when the terminal closes.
• gno mcp and other commands no longer fail at startup with database is locked while gno serve, gno daemon or the desktop app is writing to the same index. Startup syncs the collection list from the config, and when another process committed a write at the same moment, the sync failed immediately instead of waiting. It now waits its turn. An agent that starts gno mcp beside a busy GNO used to see the MCP server exit.
• gno daemon --stop and gno serve --stop no longer hang for 12 seconds and then force-kill a process that was stopped while still starting up, for example right after --detach returned. The stop signal was caught before the shutdown handler existed and then ignored. A process stopped during startup now exits at once, and --stop removes its pid file when the process could not.
• gno serve, which the desktop app runs, now catches up on notes added, edited or deleted while it was not running. It used to index only changes it saw happen, so offline edits stayed out of search until a manual sync or the next time the file changed. At startup it now reconciles each watched folder with the disk in the background, the way gno daemon already did with its initial sync. Search and status stay available meanwhile, and a folder that keeps failing backs off like any other watcher sync.
• GNO no longer leaves processes running after the process that started them is gone. The desktop app now stops gno serve when it quits, waiting for it and force-stopping it if needed, and serve shuts itself down if the app crashes or is force-quit; it used to keep running, holding its port so the next launch failed. A session import started by gno serve, gno daemon or MCP now stops when its parent dies or shuts down, and gives up after 30 minutes. A collection's updateCmd (for example git pull) now stops, together with anything it started, when gno index or gno update exits or is killed, and after 10 minutes; set updateCmdTimeoutMs on the collection to change the limit.
• A busy gno serve or gno daemon stays responsive. Under load, for example after waking from sleep with many changed notes, while indexing a burst of edits or with many open browser tabs, the status endpoint used to stall for half a second to several seconds, and status checks from the desktop app or scripts could time out. Three causes are fixed: each status check scanned every stored embedding to confirm their size (now an index lookup), every request re-read and re-parsed the config file even when it had not changed, and updating the links between notes after a burst of changes ran without pause. In soak tests the slowest status response under each of these loads dropped from up to 2.4 seconds to under 70 ms.
• A file GNO cannot read (for example a locked or password-protected file) no longer makes gno serve or gno daemon re-scan its whole folder every few minutes. After a full catch-up, such as the one gno serve now runs at startup or one after a config change, GNO records the file's error once, the way gno update does, and tries it again when the file changes. Only a temporary database failure is retried on a timer, and then just for that file.
• A note could stay in search after its folder was moved or deleted while gno serve or gno daemon was running. It happened when the note had been created shortly before: GNO tracked it, but its record of the folder's contents had not caught up yet, so moving or deleting the folder removed every other note in it and left that one behind until the next full sync. Moving or deleting a folder now also removes every indexed note under it that is no longer on disk.