v0.70.0

Minor Changes

• Settings now has one Agents page instead of two. "Configure agents" and "AI tools" each told you half the story: one showed which agents appear in your menus, the other showed which ones OpenKnowledge had wired up to read your documents. A switch could be on while the agent could not read anything, and nothing on either page said so. The merged page puts both facts on one row, so an agent that is listed and an agent that works are no longer different questions asked in different places. Old links and searches for either name still land here.

  Each row now says whether OpenKnowledge can reach that agent's tools, and offers the one action that makes sense: Add MCP & skill when nothing is set up, Manage when something is, Remove when files are on disk for a tool you have turned off, and Install when the tool itself is missing and we know where to get it. Where we do not, the row falls back to a How to set up link. Only one line appears under a row: a tool you do not have reads "Not installed" and stops there, rather than also reporting on config it has no use for.

  A row never claims more than it knows. When OpenKnowledge cannot verify a tool's setup it shows no status rather than guessing, and if the whole install-state read fails, only the connection column degrades — every group still renders, every switch still works, and the message is retryable. A switch for a tool that is not installed is inert, since turning it on would promise a menu entry nothing can serve; one you had already turned on stays live so the choice can still be undone.

  Two long-standing messages are fixed. Removing a setup whose file another agent shares now names that agent and the file and offers to remove it for both, instead of reporting "Something went wrong. Please try again." And a note about an entry OpenKnowledge did not write, or one that changed after it did, now says which file it means and what turning it on would do, and it is the only mark on that row. Previously the amber triangle stood beside the ordinary information icon, so an entry needing attention showed two marks and read as two separate problems.

  Pi, OpenClaw and Hermes gain connection rows, since each needs an MCP entry with no fallback. Claude Desktop keeps both of its rows, now told apart by name: the one that opens the app stays Claude Desktop, and the one that configures the chat client's own MCP file reads Claude Desktop (chat). They point at genuinely different files, so both have to exist.

Patch Changes

• Settings → AI tools now tells you what each option writes, and stops claiming things that weren't true.

  The per-agent setup dialog described checked boxes as "installed now — uncheck to remove". On an agent with nothing set up yet the dialog pre-selects a recommended set, so those boxes were proposals, not installed state. That sentence is gone. Every option's info tooltip now names where it writes (.codex/config.toml, .codex/skills/open-knowledge/, ~/.codex/skills/), resolved from the satisfier's own path id — so an entry that lives in another tool's file names that file, which is why Copilot's project MCP server reads .mcp.json. The user-scope skill row names its root directory rather than the installed folder, because that folder's name is a CLI-side constant with no browser-reachable export. The user-global MCP row has no path at all yet; it resolves through a CLI-side map with no browser equivalent.

  A blocked option now names the control that unblocks it ("Turn on Global MCP server first.") instead of "Select the required connection first." Option descriptions were rewritten for accuracy: the global MCP server says it covers every project on this machine, the project skill no longer promises a live preview, and the discovery skill reuses the wording already shipped in the first-launch dialog. Checkboxes align with their labels, scope headings match the sizing used elsewhere, and the setup-doc link is muted with an external-link arrow.

• Agent connections no longer deletes a skill another agent reads, applies nothing when a change conflicts, and says why a save failed.

  Removing a project or discovery skill for one agent whose skills folder is an alias of another agent's (for example .cursor/skills pointing at .claude/skills) used to follow the alias and delete the other agent's copy with no warning. The removal now stops, names the agent on the other end, and offers "Remove for both". The same rule already covered files two agents share by design, such as .mcp.json; folder aliases the host observes on disk now count too.

  The vendor-neutral .agents/skills hub counts as a peer too: a skills folder linked at the hub names LM Studio (project) or OpenClaw (machine) as the agent on the other end, and when that agent has no row of its own the removal stops and points at Skills Studio instead of offering a "Remove for both" it cannot honor. The removal confirmation now says whose folder a listed skill also is, before you click. Skill folders are only replaced when they hold a SKILL.md OpenKnowledge wrote, and a user-level skills folder aliased outside your home directory is refused rather than followed.

  A save or removal that raises a conflict used to apply every part the conflict did not touch, so the "shared with GitHub Copilot, remove for both?" question could appear after three of four files were already gone. A conflicted batch now changes nothing until you answer.

  GitHub Copilot's project skill can be installed from the workspace .mcp.json it shares with Claude Code. The skill writer only accepted Copilot's own machine-wide config as the prerequisite, so ticking just the skill failed with "Something went wrong" even though the settings row promised either scope would do. Copilot's machine-wide MCP row is also greyed out until ~/.copilot exists, matching what the writer would refuse.

  An OpenKnowledge MCP entry that was edited after OpenKnowledge wrote it (an added env key, for instance) now reads as "changed after OpenKnowledge wrote it" in Agent connections, and saving replaces it with OpenKnowledge's own entry. The docked terminal already refused to auto-approve tools for such an entry; the two views now agree. Entries nobody edited are untouched, and a version refresh still updates them in place.

  Removing one of two MCP entries a skill accepts (GitHub Copilot reads either the shared .mcp.json or its own machine-wide config) no longer withholds the removal as if the skill were losing its only prerequisite. An intent that names a control the dialog disables (a foreign entry, an agent with no config file yet, an undetected agent) is refused with that reason instead of being stepped.

  Moving or renaming a machine-wide skill now repoints every user-scope host's link, including ~/.gemini/skills and ~/.lmstudio/skills; the slot list is paired with the root map it is given instead of always enumerating the project set. The retired project-skill .gitignore block is removed through a temp file and rename, only the blank line the block left behind is collapsed, CRLF endings and whitespace-only lines are kept, and the cleanup also runs when a folder is set up fresh, not only on a managed open.

  Every check that decides whether an existing MCP entry is OpenKnowledge's own launcher (refresh in place, read as connected, or inject the transport) now looks at how the entry launches: a shell script body that opens with the # ok-mcp marker or version line, or the published package name as its own argument. A foreign command that merely mentions either somewhere in its text is no longer treated as ours, and its row no longer reads Connected.

  Refreshing OpenKnowledge's own entry in place now rewrites the env key (OpenCode's environment) along with the launcher in every format, JSON, YAML and Codex's TOML alike, dropping any value that was added after OpenKnowledge wrote it, since that environment lands on a process OpenKnowledge spawns. On that in-place refresh, every other key the harness owns, such as cwd, startup_timeout_ms or Codex's tools tables, keeps its value, its shape and its comments; the TOML writer removes the one key through the native editor instead of rebuilding the entry. When Agent connections turns an entry on, the entry is replaced whole in every format, so a foreign entry under our name never keeps its keys, and an entry that was edited after OpenKnowledge wrote it is replaced whole too, extras included. The overwrite is offered for TOML only where the native writer is available. An agent that never asked for an exact-match check, such as Codex, now still reads as "changed after OpenKnowledge wrote it" when its entry carries a managed key OpenKnowledge did not write (an env map, even an empty one), so the row offers the replacement instead of reading Connected. The three unattended sweeps, ok start, the desktop app start and the desktop project open, use that same check: when OpenKnowledge's own launcher carries such a key, the sweep removes only that key and leaves the launcher itself untouched, so a launcher newer than the running build keeps its body and still loses the foreign environment. A prune never creates a file or a folder, reports as no change when there was nothing to remove (as its own status and its own event, so a planned removal that found nothing is never mistaken for a clean entry, and ok start warns about it instead of staying silent), and is only logged as done after the write succeeded; for a TOML config it needs the native writer, and where that writer is missing the desktop start reports the refused prune as a failure instead of a healthy machine and ok start warns about it with the reason. The desktop start treats a prune that removed nothing the same way, and its failure notice now names the agent and the reason and still lists the agents it did repair in the same run. Both of ok start's sweeps, the MCP config repair and the launch.json cleanup, stamp every event with a severity, so ok start warns on anything it does not know to be routine and stays quiet on routine work.

  The GitHub Copilot project skill only counts an MCP entry as its prerequisite when that entry actually runs OpenKnowledge: the shell launcher, a legacy npx entry that names the published package, or the dev launcher ok init --dev-mcp writes, and never an entry the host has disabled. It learns which shared file to read from the agent registry instead of naming Claude Code by hand. Moving a machine-wide skill in place records its slot under the right root for the scope being moved.

  When two parts of one save fail for different reasons, the dialog lists each part with its own reason instead of naming only the first. When a save will replace an entry or folder that is not OpenKnowledge's, the button reads "Replace and save". Saves made from a browser now carry the transport failure, the HTTP status, or the unexpected response shape into the error line.

  Failures name their reason instead of "Something went wrong": a config file the agent has not created yet, a file OpenKnowledge could not parse, a skill whose MCP entry could not be written, a write that failed, or an MCP entry unticked while a skill that needs it stays on. A build that cannot manage connections says so once at the top of the page and shows no Add or Remove buttons, rather than failing every save. Terminal rows' Install links now open the vendor's install page from the agent registry.

  The "one more step" hint is back on connected rows. When OpenKnowledge has written an agent's project MCP entry but the agent still needs something from you, the row says so under its status: run Claude in the project and approve OpenKnowledge once, enable the server in Cursor's Tools & MCP settings, or open the project in a trusted Codex or GitHub Copilot session. The hint is worded per agent from one translated string each, and the catalog check now fails when any locale is missing one of them, instead of passing on an empty set.

  Turning on a skill that needs an MCP entry no longer picks that entry by list position. When more than one entry would do, OpenKnowledge prefers one the agent owns alone over one borrowed from another agent's file, and among those, one that connects without a follow-up step. GitHub Copilot's project skill therefore adds Copilot's own machine-wide entry rather than writing into the .mcp.json it shares with Claude Code; the shared file is used only when the owned entry is unavailable.

  The notice the desktop app shows after its start-up repair now survives being opened through a link on Windows and Linux. On those platforms a link opens the app into a first window that is replaced or reloaded by the project window a few seconds later, and the notice used to go to the first one only, so a failed repair was never seen. The notice now reaches every window loaded in the first minute after the repair.

• A row you cannot change now tells you why, instead of saying the same thing in every case.

  "This option cannot be changed automatically" covered four unrelated situations. An agent you have installed but never opened, an agent OpenKnowledge cannot find at all, and an agent that offers no way to be set up for you all read identically, and none of them hinted at what to do next. Each now says its own thing, and the one you can act on tells you to open the agent once and check again.

• Built-in skills installed for Copilot, Pi, Antigravity or LM Studio are visible again.

  A user-global skill lives under that agent's own folder, and four of them sit somewhere other than where the project-scoped copy would go: ~/.copilot/skills, ~/.pi/agent/skills, ~/.gemini/skills and ~/.lmstudio/skills. OpenKnowledge seeded built-ins into all four but then looked for them in the project locations, so a built-in installed for one of those agents had no source shown and no update offer, its SKILL.md would not open, and deleting the skill left the copy behind.

  Scope now picks the folder map, so those four are read, listed and cleaned up like every other agent's.

• The remove confirmation now names the config file it is about to edit.

  Removing OpenKnowledge from an agent showed a line reading "Global MCP server" and nothing else, so there was no way to tell which file was about to change. It now shows the path, for example ~/.lmstudio/mcp.json.

  The path was missing because the window cannot work it out on its own: these locations depend on environment variables and per-agent fallbacks that only the OpenKnowledge process resolves. It is now reported by the part that looks the file up, so the confirmation names the real file rather than a guess.

• LM Studio is recognised when you have it installed.

  Its row in Agent connections always read "Not detected on this machine", even with the app right there, because OpenKnowledge never actually checked for it. OpenKnowledge asks the operating system which app owns a link type, and LM Studio does register one, so it is now asked about like every other app.

• You can now reconnect an agent whose open-knowledge MCP entry you edited by hand.

  An entry OpenKnowledge did not recognize used to turn that row off entirely, with nothing to click and no way forward. Editing that entry yourself was enough to lock yourself out of the row that manages it. The row is now live, and its warning says plainly that ticking it replaces what is there.

  It stays unticked when the dialog opens, which is the point: every other row on a fresh dialog opens ticked, and replacing a file you edited should be something you reach for rather than something that happens because you saved a dialog you opened to look at. The Save button turns red while such a change is in the draft. Nothing outside that one entry is touched, so other servers, comments, and formatting are left exactly as they were.

  This applies to agents whose config is JSON, which is where OpenKnowledge can replace its entry outright. Codex, Hermes, and Pi keep the entry read-only, because on those formats OpenKnowledge merges its own keys into what is already there rather than replacing the whole entry, and a merge would leave part of your edited entry attached to a server OpenKnowledge starts.

  Setting up a skill that needs an MCP entry still will not quietly overwrite one you edited. That work is held back, and the dialog now names both rows and tells you which one to tick.

• Connecting a tool no longer leaves part of someone else's MCP entry attached to OpenKnowledge's.

  If an entry named open-knowledge was already in the file but launched something else, setting the tool up rewrote the launch command and left the rest of that entry behind — so OpenKnowledge's own process could end up running with environment variables it never set. The entry is now replaced outright, which is what claiming the name has to mean.

  OpenKnowledge's own entry is still updated in place: a version bump refreshes the launcher and keeps everything around it, so a working directory you added, a timeout, a per-tool approval setting, or a disabled flag all survive. Nothing outside that one entry is touched either way — other servers, comments, and formatting are left exactly as they were.

• Agent connections no longer offers an agent options it does not have.

  Every agent's Configure dialog showed the same four checkboxes — project and global MCP server, project and discovery skill — with the ones an agent has no surface for greyed out. Pi has no machine-wide MCP config at all, so its global row could never be ticked; Claude Desktop, Hermes, OpenClaw and Antigravity have no project-scope surface of any kind, so their whole This project group was two dead rows under a live heading. A disabled control reads as something OpenKnowledge failed to set up, which sent people looking for a fix that does not exist.

  Those rows are gone now, and a group with nothing left in it drops its heading rather than standing empty. An option that genuinely exists but cannot be written right now still shows, disabled, with the reason — an entry OpenKnowledge did not author, a host with no scriptable installer, an agent that is not on this machine. That distinction is the point: nothing to offer and cannot act are different answers and now look different.

• One less row in Settings: OpenKnowledge no longer sets up Claude Desktop.

  OpenKnowledge stopped integrating with Claude Desktop's Cowork tab a while ago, which left it as a single MCP config file OpenKnowledge wrote and a settings row whose only job was letting you undo that write. Neither earns its place, so setup no longer offers Claude Desktop and no longer writes to claude_desktop_config.json, and the row is gone.

  If you want OpenKnowledge in Claude Desktop, add the MCP server to that file yourself — it is an ordinary MCP config.

  An entry an earlier version wrote is left exactly as it is, so Claude Desktop keeps working as it does today. To clear it, either delete the open-knowledge entry from claude_desktop_config.json yourself, or run ok uninstall, which removes OpenKnowledge from every agent on the machine.

• OpenKnowledge no longer writes built-in skills into your agent folders on its own.

  Launching the app used to keep re-installing a skill you had already said yes to into every agent home folder it found, including ones you added after that first yes. ok start did the same on every boot, and opening a project you had already set up created its project skill for any editor that was missing one. Installing a skill is something you ask for, so all three are gone.

  Launch still does two housekeeping passes that write nothing new: it removes superseded copies OpenKnowledge itself left in your agent folders under an older name, and it removes a bundle you switched off that is still on disk.

  Skills are now written by ok init's permission prompt, by Skills Studio, and by the Settings toggles. Nothing else.

  One thing to know: a project's skill folder is deliberately kept out of git, so someone cloning a project you set up will not have its OpenKnowledge skill until they turn it on. ok repair-skills still runs an explicit repair.

  Nothing already installed is removed or changed.

• The ok terminal command has a home again, under Settings → Preferences.

  The settings rework replaced the old AI tools page with Agent connections, and the checkbox that adds the ok command to your shell did not come with it. It kept working — anyone who had switched it on still had it — but there was no longer a way to switch it back off. It now sits on User → Preferences, just under Theme, where the rest of the "how OpenKnowledge behaves on this machine" settings live. It appears only in the desktop app, and only when there is a shell to add it to or a block already installed.

• The discovery-skill checkbox in Settings → Agent connections works, instead of sending you to Skills Studio forever.

  Two things were wrong. The row read the wrong directory: it looked for the project bundle (open-knowledge) inside the user-global skills root, where the discovery bundle (open-knowledge-discovery) actually lives. So a discovery skill you had already installed read as missing no matter how many times you installed it, and the row kept offering to add it. And the box it offered could not be saved: the user-global rows had no per-agent writer, so every Save came back failed with an error pointing at Skills Studio, which lists a different set of agents and could not always honour the request either.

  Each agent's row now installs and removes its own copy, in its own skills folder, leaving every other agent's alone. Both directions decline when two agents' skills folders resolve to the same directory, naming what shares it — installing through the alias would have made the other agent's row read as set up off a write you never asked for, and you could not have undone it from the same screen.

  Turning a row on also records that you want the skill, so a machine-wide decline made during onboarding no longer removes it again at the next launch; turning off the last agent that had it records that too, so it does not come back everywhere.

  A row is only offered for an agent whose folder is already on your machine — the option reads as unavailable rather than sitting checked and failing on save — which is the same rule Skills Studio uses, so the two screens agree about which agents can take a machine-wide skill. Creating the folder would have meant more than the one box you ticked: OpenKnowledge treats the presence of that folder as proof the tool is installed, so the next launch would have seeded your other enabled skills into it too.

• Agent connections no longer makes you set things up in a particular order.

  A skill row that needed an MCP server was greyed out until you ticked the MCP first, which asked you to sequence two changes OpenKnowledge already sequences for you: saving a skill whose MCP entry is missing installs both, in the right order. The rows are independent now, and the change counter tells you what a save will do.

  GitHub Copilot was the row where this bit hardest. It reads OpenKnowledge from either the project file it shares with Claude Code or its own machine-wide config, and having one is enough — but the requirement was written as needing both, so a Copilot user with neither could never clear it. It now asks for either, and a save installs one rather than writing a second entry Copilot never needed.

• LM Studio now gets OpenKnowledge's project skill.

  LM Studio reads a project's skills from <project>/.agents/skills, the shared folder several tools read, rather than from a folder of its own. OpenKnowledge only ever wrote its project skill into per-editor folders, so picking LM Studio during setup connected it but never gave it the guidance that tells an agent how to use OpenKnowledge in your project.

  Setup now writes the project skill into .agents/skills when you pick a tool that reads it. It is written once for the project, and only when you picked such a tool — nothing appears there otherwise.

• OpenKnowledge no longer forces its project skill out of your git history.

  Setting up or opening a project used to append a .gitignore block excluding the built-in open-knowledge skill, and, if the skill was already committed, make a commit removing it. Both existed for one reason: the app rewrote the skill on every open and stamped a version into it, so two people on two app builds fought over the file. The version stamp went away, and the app no longer rewrites it on open, so neither is needed.

  Whether the skill is committed is now your project's decision, exactly like any skill you wrote yourself. Committing it means a teammate gets it on clone, and updating it shows up as a reviewable change instead of happening quietly on each machine at a different time.

  Because those lines were written to every project anyone opened, opening a project (or running ok init) now removes them again. That is the only thing an open still does to .gitignore, it only ever deletes lines OpenKnowledge itself wrote, and it edits the working tree without staging or committing, so you see it as an ordinary change and can keep or discard it. Your own lines are untouched.

  ok deinit still removes the skill as part of OpenKnowledge's footprint.

• Turning off a project's Agent Skill for one editor no longer deletes it for another that shares the same folder.

  Each editor gets its own project skills folder, but some setups point two of them at one place — .codex/skills symlinked to .agents/skills is a common one. In that layout, removal followed the link: switching the skill off for Cursor deleted the bundle Claude was reading, and Claude's row went on showing it as installed. Removal now declines when the folder is shared, naming what shares it, rather than repointing a link you set up yourself. The shared .agents/skills hub counts too, since several tools read it directly. An alias that nothing else reads still removes normally.

• The remove dialog lists real file paths again.

  Under "this deletes the MCP server entries and skill files listed below" it was printing OpenKnowledge's internal key for each location, so a row about your project's .mcp.json read editor-project-config:claude. It now shows the path, and shows nothing at all for the rows that have no file behind them.

• A connected agent no longer offers you its setup guide.

  LM Studio's row read "How to set up" next to "Connected" — instructions for something you had already done, in place of the one action the row actually had. Because OpenKnowledge cannot complete LM Studio's setup for you, the row assumed there was nothing to do, and never noticed the setup was already there. It now offers Remove once the entry and skill files exist, and keeps the setup guide for when they do not.

• Linking two agents to one skills folder no longer makes that row unusable.

  Skills Studio lets you point one agent's skills folder at another's. Agent connections then refused to install or remove anything in that folder, because a change there reaches both agents. One part of OpenKnowledge was offering the link and another was refusing to work through it, and the row said only "Something went wrong."

  The row now works, and says what it will do: "This folder is also Claude's. Turning this on or off does the same for them." Installing goes through and reaches both, which is what sharing a folder means. Removing stops first and asks, naming the other agent, so one row cannot silently take the other's copy with it.

  Both rows say it, including the one that owns the folder. With ~/.codex/skills pointed at ~/.claude/skills, Claude is the side with something to lose: unticking Codex takes Claude's copy with it, so Claude's row is the one that most needs to say so.

  The two features also stop deriving this separately. Which folders are really the same folder is now read once, from the same scan Skills Studio uses when it offers the link, and compared on the resolved path rather than on the label shown next to the folder.

• The docked terminal no longer tells you Claude Code's Open Knowledge tools aren't connected when they are.

  Claude Code reads two config scopes — your user-global ~/.claude.json and the project's .mcp.json — but the terminal's readiness check only looked at the global one. A project that carries Open Knowledge's MCP entry locally, with nothing configured globally, got a persistent "tools aren't connected" strip despite the tools working. Readiness now treats either scope as sufficient, and records which one supplied it. A user with neither still gets the nudge, unchanged.

• Open Knowledge's tools are now auto-approved in the docked terminal when its MCP server lives in your user-global Claude Code config, not only when it lives in the project.

  Two different things had been riding one switch. Trusting the project's .mcp.json server entry and auto-approving Open Knowledge's tools are separate decisions, and both were gated on the project entry — so anyone whose server was configured globally got neither, and had to answer a tool prompt on every launch. They are now decided independently. A foreign server that happens to be named open-knowledge in the project still disables auto-approval outright, even alongside a legitimate global entry, and the auto-approve preference remains the last word in every case.

• A command-line tool you do not have installed no longer shows as turned on.

  In Settings, rows under Terminal could read "Not installed" next to a switch that was on and could still be flipped. The row asked whether the tool was installed in two different ways and they disagreed while one of the answers was still coming in. The switch now follows the same answer the row shows you, so a tool you have not set up reads off and stays off until you install it. Turning one on deliberately still works and still points you at its installer.