Myles AndersonandClaude Opus 5
c5b49fe37f
* feat: simplify the skills experience The Customize tab was five sections deep in choices that no longer earned their place: a Global/This project scope picker on every card, a separate "import from your agent" list, and two split skill lists. - Skills installed in a coding agent are now mirrored automatically — read live from its skills dir on every listing and every session write, so a skill edited in Claude Code is the one the next session runs. The import step and its two endpoints are gone. A session hosted by the agent a skill came from is not handed a copy it already loads. - Claude Code's installed plugins are mirrored too, discovered through installed_plugins.json so only real installs count. - Every skill and LaTeX template is global. Project scope is removed from the store, the API, and the UI; anything already saved under it is migrated into the single store on first access. - Skill frontmatter is parsed the way skills are actually written: folded and literal blocks, and values wrapped over indented lines. A skill whose frontmatter we cannot read is a skill the user never sees. - ~/.agents/skills is read whenever it exists, rather than only when ~/.codex does. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: harden the skills mirror after review Review of the mirroring change turned up defects worth fixing before it ships: - A plugin's skills are registered namespaced (`runpod:flash`), so the bare `/name` only resolves from a copy. They are no longer treated as natively loaded by the agent that installed them. - Uploaded skills resolve through their folder name again, not the frontmatter `name` a hand-edit can change out from under them. - The hosting agent's own skills are dropped only after they have won their `/name`, so a same-named skill from another agent can't take their place in the worktree while the dashboard shows the first. - Session skill dirs are replaced and pruned only when the manifest says we wrote them, so a `.claude/skills` the project itself commits is left alone; manifest names are re-validated before any removal. - A folder whose source is unchanged is not re-copied, folders over the upload budget are skipped, and neither the copy nor the size walk follows symlinks. - The retired per-project store is emptied, never deleted: anything that can't move stays put as the user's only copy. - A `#` comment no longer folds into the value above it, and a long description truncates instead of dropping the skill. - The Customize tab distinguishes a failed skills fetch from an empty one, and ignores drops while an upload is in flight. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: keep one answer for what a skill name resolves to Second review round: - `source_dirs` resolves uploads through the same listing the dashboard reads, so a folder whose SKILL.md won't parse can't win a name in the worktree while the tab shows the mirrored skill it shadowed. - A folder tally now carries a digest over every (path, size) pair, so a rename or a move inside a skill brings the session copy forward; each source and destination is walked once per turn instead of three times. - A destination whose content already matches its source is adopted as ours, so a lost manifest heals instead of freezing that skill forever. - A mirrored folder over the upload budget is left out of the listing too, rather than offering a `/name` that never reaches the worktree. - LaTeX templates get the same skip-if-unchanged treatment. - Archive junk under the retired per-project store no longer keeps it alive on every call. The freshness test now watches the inode: `fs::copy` carries the mtime across on macOS, so the timestamp it asserted on could never have failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: never let an adopted skill dir become prunable Round three: adopting a destination whose content already matches its source healed a lost manifest, but it also recorded a directory orx had never written — so once the source went away, the prune deleted a skill the project itself commits. Adoption is now limited to the case it was for: no manifest at all. While a manifest exists it stays the whole truth about what we own. Also from that round: the upload budget moved into `source_dirs`, so the menu, the hover preview and the session write agree on which `/name` exists; a stray `.DS_Store` beside the retired per-project store no longer keeps it alive; and the uncapped walks stopped pretending they can fail. The fingerprint test never reached the SKILL.md byte comparison it was supposed to cover, and the migration test never asserted the retired tree was gone — both fixed, and both verified by reverting the fix under them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * refactor: one budget answer for uploads too The listing kept sizing uploads with an uncapped walk while the resolver had started budgeting them, so a hand-edited store could list a skill no session would be given. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
OpenResearch
The local-first workspace for research agents and autoresearch.
Turn 
Claude Code,
Codex, or
OpenCode into research agents that can review
literature, develop hypotheses, run experiments, and produce research artifacts.
Get started
Download the local desktop app from openresearch.sh/download, or install the CLI on macOS or Linux:
curl -LsSf https://openresearch.sh/install.sh | sh
orx up
orx up opens the local dashboard at http://127.0.0.1:4791.
Create an account at openresearch.sh to receive email updates and use managed OpenResearch compute.
Built for research agents
| OpenResearch gives you | |
|---|---|
| Parallel exploration | Give each research direction an independent agent session and isolated git worktree. |
| Reproducible experiments | Track variants in a git-native experiment tree; every run receives an immutable archive of its recorded commit. |
| Evidence in context | Keep logs, diffs, files, results, and artifacts tied to the work that produced them. |
| Your choice of agent | Use Claude Code, Codex, or OpenCode, with the harness and model selected per session. |
| Your choice of compute | Run locally, on your own infrastructure, or with managed OpenResearch compute. |
| Local ownership | Keep projects, conversations, experiments, runs, logs, code, and artifacts on your machine. |
Autoresearch
OpenResearch can run the full loop autonomously: propose an idea, change the code, launch an experiment, inspect the evidence, and decide what to try next. Multiple agents can explore different directions in parallel while the experiment tree preserves their lineage.
Run anywhere
The same committed source snapshot can run locally, over SSH, or on Slurm, Kubernetes, Ray, Hugging Face Jobs, Modal, Tinker, and managed OpenResearch compute. Publishing the repository is not required.
Run the workspace next to remote GPUs while using the browser on your laptop:
orx up --remote user@host
SSH config aliases and custom ports are supported. The remote service binds to loopback and has no application-level authentication, so other users on that host can reach it.
CLI and agent integration
Install the OpenResearch skill into supported coding agents:
orx install-skills
Common commands:
orx projects
orx project view <project-id>
orx runs <project-id>
orx logs <run-id>
orx exp run <experiment-id>
orx discover keyword <query>
orx paper <arxiv-id-or-doi>
Run orx --help or orx <command> --help for the complete interface.
Local by default
OpenResearch runs on 127.0.0.1 with a local SQLite store. Creating a project
or launching a run does not publish your code. An
openresearch.sh account is only used for
service-owned capabilities such as organizations and managed compute.
Usage analytics
Official release builds send opt-out, coarse usage events tied to a random installation ID. They do not include code, prompts, file contents or paths, repository names, tokens, emails, or project and experiment identifiers.
orx telemetry off
orx telemetry status
orx <command> --no-telemetry
Source and development builds do not send analytics.