How to update the loom command and its harness integrations, remove one integration, or remove Loom from a computer without losing access to your stores.
Keep
~/.loom/stores.toml. It is the only local copy of your store connection details. Every step below preserves it unless you are told otherwise.
Finish or checkpoint active agent work first, then re-run the installer and setup. Both are safe to repeat, and setup needs no sign-in when stores.toml already holds your credentials.
curl -fsSL https://loomcloud.ai/.well-known/cli/install.sh | sh
loom setupirm https://loomcloud.ai/.well-known/cli/install.ps1 | iex
loom setupWhat each step does:
| Step | Effect |
|---|---|
| Installer | Replaces the runtime under ~/.loom/cli in one step, using a staging directory and a rename, and leaves no backup copy after a successful install. Does not touch stores.toml. |
loom setup | Re-detects Claude Code, Codex and OpenCode, runs each harness's update commands instead of the install commands, verifies each one, and prints a per-harness result with any restart needed. |
Setup updates a plugin only from the marketplace it was installed from. If the installed loom marketplace for Claude Code or Codex comes from another server than the one setup chose, that harness shows FAILED -- ... the existing Loom marketplace comes from <listed source> but this setup is for <base> ... and nothing is changed; the row names the commands to switch (see Claude Code and Codex). With an http:// server, setup skips the Claude Code and Codex plugins (claude skipped (plugins need an https server)), still updates your stores, and exits with status 3.
The installer prints a checksum line (loom-cli-bootstrap.tar.gz: OK), Loom command installed: ... and Loom runtime environment: ..., adds a PATH hint if ~/.local/bin is not on your PATH, and (macOS and Linux, when it uses its private uv) the lines Loom put its private uv on PATH for new terminals. For this terminal, run: and . "$HOME/.loom/env". It ends with Next: run 'loom setup' to connect this machine to your Loom store. ("hosted store" before v0.674). A first install on a machine without uv also prints uv was not found; installing a private copy into ...; an update does not, so the output differs slightly. It does not print the version; run loom --version.
If none of Claude Code, Codex or OpenCode is installed, loom setup stops with loom setup: no supported harness found on this machine (looked for: codex, claude, opencode). Install one and re-run. and changes nothing. Use loom login to refresh your stores only.
An ordinary update keeps your stores: ~/.loom/stores.toml is left byte-for-byte unchanged. Re-running loom setup does not ask you to sign in again when stores.toml already holds your credentials for the server (v0.674 or later): it prints Using your existing Loom stores for <server>; run loom login to sign in again. and only updates and verifies the harnesses. Releases before v0.674 always asked for your email address, consent (I agree) and a fresh sign-in code. Run loom login to sign in again on purpose, for example to see a changed Terms or Privacy Policy in the consent step or to fetch stores created since (see Re-running and updating).
Check the result:
loom --version
loom 0.664.0The version printed is the one that was released; yours will differ.
Claude Code and Codex sessions check at start-up whether a newer Loom plugin is published. The check compares the installed plugin version with the marketplace snapshot, and probes the marketplace for new commits at most once every 24 hours (from v0.674 a failed probe counts too, so an unreachable marketplace is tried once a day, not at every session start). If a newer plugin exists, the session prints the two refresh commands for that harness, a reminder to restart the harness, and a pointer to rerun the loom-install skill. The marketplace it probes is the one the plugin was installed from: loomcloud.ai for a hosted install, your own server for a plugin installed from your private server. The check never blocks a session and fails silently if it cannot reach the marketplace. Setting LOOM_PLUGIN_AUTOUPDATE=1 makes the check run the refresh commands itself instead of only printing them.
You normally do not need these, because loom setup runs them. They are the commands it uses:
claude plugin marketplace update loom
claude plugin update loom@loomcodex plugin marketplace upgrade loom
codex plugin add loom@loomopencode auth login https://loomcloud.aiOpenCode has no separate update step; signing in again refreshes it. For a private server use your own origin: opencode auth login https://<your-host>.
Use that harness's own removal step. This does not remove the shared loom command or your stores. On a hosted account it also does not delete your hosted account or hosted data; for deletion requests see Account and organization or email info@loomcloud.ai.
claude plugin uninstall loom@loomcodex plugin remove loom@loom
codex plugin marketplace remove loom # optionalOpenCode has no plugin command; delete the files:
rm ~/.config/opencode/plugins/loom.ts
rm -r ~/.loom/opencodeDelete the mcp_servers.loom block from ~/.hermes/config.yaml.
Then run loom setup to confirm the remaining harnesses are still verified. This works only if at least one supported harness remains; otherwise setup stops as described above. See the harness guides for more detail. Not tested live: the Codex, OpenCode and Hermes removal commands.
loom command#The loom command is a launcher plus a private runtime. Remove them in this order and keep stores.toml.
rm ~/.local/bin/loom
rm -r ~/.loom/cli ~/.loom/venvThis leaves ~/.local/bin in place; it is empty unless the installer linked uv into it (see below) or you keep other tools there.
Remove-Item "$env:USERPROFILE\.loom\bin\loom.cmd"
Remove-Item -Recurse "$env:USERPROFILE\.loom\cli", "$env:USERPROFILE\.loom\venv"The installer may also have put a private copy of uv and uvx in ~/.loom/bin (about 50 MB). On macOS and Linux, v0.672 or later also added # Loom: put its private uv on PATH and . "$HOME/.loom/env" to your shell startup files (~/.profile, ~/.bashrc, ~/.zshrc, ~/.bash_profile where present), wrote ~/.loom/env (and ~/.config/fish/conf.d/loom-uv.fish when fish was your shell), and may have linked ~/.local/bin/uv to the private copy. To remove the private copy and those traces:
rm -r ~/.loom/bin
rm -f ~/.loom/env ~/.config/fish/conf.d/loom-uv.fish
[ -L ~/.local/bin/uv ] && [ ! -e ~/.local/bin/uv ] && rm ~/.local/bin/uv # dangling link left behindThen delete the two Loom lines from the startup files above; until you do, new shells print No such file for ~/.loom/env, and a sh startup script that sources ~/.profile stops.
Remove-Item -Recurse "$env:USERPROFILE\.loom\bin"Open a new shell (or run hash -r) afterwards so it forgets the old loom location. Do not delete anything else in ~/.loom (apart from ~/.loom/env and ~/.loom/bin, described above).
loom logout --params '{"section":"coding"}'logout removes that store's section from stores.toml on this computer only. It does not revoke the credential on the server, and a copy of the credential on another computer or in a backup keeps working. If that section was the default, the default = line is removed too. To reconnect later, run loom login.
loom drop_store SECTION --confirm SECTION destroys the store on the server and then removes its local section. It cannot be undone. See Manage stores.
If anything fails during an update, see Troubleshooting.