opencode-studio: a local GUI for editing OpenCode config without touching JSON
web GUI for securely managing local OpenCode configuration
At a glance
- What is it?
- opencode-studio is a Next.js frontend plus an Express API that reads and writes the files under ~/.config/opencode/ directly. It is useful if you keep losing track of MCP servers and skill files, and wrong if you want a hosted, multi-user config service.
- Who is it for?
- Adopt opencode-studio if you run OpenCode locally on one machine and want a UI for MCP toggles, skills and auth profiles, accepting that the backend writes straight to ~/.config/opencode/ with no undo. Do not adopt it for shared or headless machines, or if you need a server-side approval step before config changes.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: OpenCode config is a pile of files you edit by hand
OpenCode keeps its state in a directory tree, not a single settings screen. The README lists three locations: opencode config at ~/.config/opencode/, studio data at ~/.config/opencode-studio/, and profiles at ~/.config/opencode-profiles/. Inside the first one you get opencode.json plus skill/ and plugin/ folders. Toggling an MCP server means opening opencode.json, finding the right block, and removing or commenting an entry. Adding a skill means creating a directory with a SKILL.md file in it. The README's troubleshooting table confirms the failure mode: if skills do not appear, the fix is to check that ~/.config/opencode/skill/ actually contains SKILL.md files. There is nothing wrong with this design, but it does not scale past a handful of servers and skills, and it gives you no overview of what is currently enabled. opencode-studio targets exactly that gap: a local web GUI where MCP servers are switches, skills are files in a Monaco editor, and auth is a login/logout screen. The stated audience is the individual developer running OpenCode on their own machine, not a team provisioning config for others.
Architecture: a browser talking to an Express process that owns the config directory
The README's flow diagram is short and worth taking literally. A browser sends HTTP to an Express API listening on port 1920 or above. That API reads and writes ~/.config/opencode/, which contains opencode.json, skill/ and plugin/. The four steps are named: detect, read, edit, save, with save described as writing back to disk instantly. So there is no database and no sync layer. The Express process is the only component with filesystem access, and it is the thing you install globally as opencode-studio-server. The frontend is a separate Next.js 16 application under client-next/, with pages for mcp, profiles, skills, plugins, auth, settings and usage. The repository root package.json runs both with concurrently. Two consequences follow from this shape. First, the GUI is only as safe as the machine it runs on, because anything that can reach the Express port can presumably reach the config writer; the README does not describe authentication on the API itself, only a confirmation dialog for deep links. Second, profiles are implemented as separate directories under ~/.config/opencode-profiles/, so switching a profile is a filesystem swap rather than a merge. The README does not explain what happens to in-flight sessions during that swap.
Getting it running: two install paths and the ports they bind
The recommended path is a global npm install of the backend only, then using the hosted frontend. The README gives this as `npm install -g opencode-studio-server`, after which you visit opencode.micr.dev and click Launch Backend in the sidebar. The fully local path uses the bundled scripts: `quickstart.bat` on Windows, or `chmod +x quickstart.sh && ./quickstart.sh` on macOS and Linux, then open http://localhost:1080. Ports auto-detect. The README states the backend starts at 1920 and up, and the frontend at 1080 and up, so a conflict shifts both rather than failing. Several features have their own prerequisites that are easy to miss. GitHub sync requires `gh auth login` to have been run first. The protocol handler for opencodedstudio:// deep links needs `opencode-studio-server --register` run as admin, which is a real friction point on locked-down machines. The deep link scheme itself has five documented forms, including `opencodestudio://install-mcp?name=NAME&cmd=COMMAND` and `opencodestudio://import-skill?url=URL`, all requiring URL-encoded parameters. The README also notes that GitHub blocks custom protocols in user content, so install buttons placed in a repository need a redirect page on GitHub Pages to work.
Where the design gets thin: instant writes, unclear licence, and a truncation
The save step is described as writing back to disk instantly, and the README does not mention versioning, a diff preview, or an undo. Backup and restore exist as a feature, exporting and importing complete config including skills and plugins, but that is a manual snapshot you take deliberately, not a safety net around each edit. If you fat-finger a system prompt in the settings page or delete an MCP entry, the README offers no recovery path short of your own backup. The licence is a second uncertainty. The README carries an MIT badge linking to LICENSE, but the repository metadata supplied here lists the licence as unknown. Those two signals disagree, and the badge is not the licence file. Treat the terms as unconfirmed until you open LICENSE yourself. Third, the supplied README is truncated mid-sentence in the troubleshooting table, at the row about agents not showing in OMO format. That row is cut off, so the documented fix for missing oh-my-openagent agents cannot be quoted in full. Finally, the feature list is broad enough that depth is a fair question. MCP management, profiles, skills, plugins, commands, agents, usage analytics, auth, GitHub sync and backup all live in one Express file, server/index.js, according to the project structure.
The alternative is the editor you already have open
The honest comparison is not another GUI. It is editing ~/.config/opencode/opencode.json plus the skill/ and plugin/ directories directly, in whatever editor you already use. The difference is not cosmetic. A text editor gives you grep across the whole config tree, git diffs on every change, and the ability to keep the directory in a repository you control, which is roughly what the GitHub sync feature reconstructs through the gh CLI. opencode-studio trades that for discoverability: a switch instead of a JSON key, a template picker instead of a directory you have to scaffold correctly, and a bulk import that previews multiple raw GitHub URLs with checkboxes before writing anything. The bulk import flow is the strongest argument for the GUI, because fetching three SKILL.md files by hand and placing them in the right subdirectories is tedious and easy to get wrong. Conversely, if your config is small and stable, the GUI adds a Node process, a Next.js build and two port ranges to manage in exchange for editing a file that rarely changes.
Maintenance cost and what a new release actually means for you
The release cadence visible here is three versions in roughly two months: v2.4.3 on 2026-07-16, v2.4.4 on 2026-07-22, v2.4.5 on 2026-08-08. That is frequent enough that pinning matters. Because the recommended install is global, `npm install -g opencode-studio-server` will pull whatever is latest, so a patch release lands on your machine the next time you reinstall. If you want to stay on a known version, the npm package name is opencode-studio-server and standard npm version pinning applies. The upgrade surface itself is narrow, since the only persistent state the tool owns is ~/.config/opencode-studio/ and the profile directories; the config it edits belongs to OpenCode. That separation is a point in its favour for upgrades, but it also means a schema change in OpenCode's own opencode.json could leave the GUI reading a shape it no longer expects, and the README does not state which OpenCode versions are supported. On licensing, the README's MIT badge and the unknown metadata status need reconciling before you redistribute anything based on this repository, and I am not in a position to give you legal advice on which one governs.
Who should install it, and the three things to check first
Install it if you run OpenCode on a single local machine, you have accumulated enough MCP servers and skills that you no longer remember what is enabled, and you would rather click a switch than hand-edit opencode.json. The profiles feature is the other reason to bother, since isolated environments with separate configs, history and sessions are genuinely awkward to maintain as directories by hand. Skip it if the machine is shared, headless, or remote, because the Express API on port 1920 plus has no documented access control, and if you need a review step before config changes land, the instant write-back is the wrong model. Three checks before you commit. Open the LICENSE file and confirm it says MIT, since the repository metadata here does not. Back up ~/.config/opencode/ yourself, because the tool's own backup feature is something you invoke, not something that runs before each save. And if you plan to use deep links for one-click installs, test `opencode-studio-server --register` as admin on your target OS early, since that is the step most likely to be blocked by policy.
Editorial conclusion
Adopt opencode-studio if you run OpenCode locally on one machine and want a UI for MCP toggles, skills and auth profiles, accepting that the backend writes straight to ~/.config/opencode/ with no undo. Do not adopt it for shared or headless machines, or if you need a server-side approval step before config changes. Before installing, confirm the LICENSE file matches the MIT badge, check whether the --register protocol handler needs admin rights on your OS, and verify that your existing ~/.config/opencode/opencode.json is backed up, because the save step writes back to disk instantly.
Community notes