374e9de719
* feat: add opencode support
* fix: stabilize opencode session startup
* fix: /models
* fix: improveUI for commands
* fix: format commands.js
* feat: load models through provider adapters
Provider model selection had outgrown a single hardcoded service.
The old service mixed shared caching with provider catalogs and CLI lookup details.
That made stale model lists more likely as providers changed on separate schedules.
Move model discovery behind each provider so lookup lives next to the integration.
The shared service now focuses on provider resolution, caching, persistence, and dedupe.
Return cache metadata and add bypassCache because model availability changes outside the app.
The UI and /models command can show freshness and let users force a provider refresh.
Surface model descriptions while keeping fallback catalogs for unavailable CLIs or SDKs.
* feat(models): resolve active session models through provider adapters
The model inventory command was showing a mix of catalog defaults and
composer-local state instead of the model that is actually active for a
real provider session. That made /models, /cost, and /status
misleading once a session had already started, especially for providers
whose effective runtime model can differ from the optimistic model value
held in the UI.
Introduce an explicit getCurrentActiveModel() contract on
IProviderModels so model resolution lives next to each provider's
catalog logic and uses the provider-native source of truth:
- Claude reads the init event from a resumed stream-json run
- Codex reads model from ~/.codex/config.toml
- Cursor reads lastUsedModel from the chat store.db
- OpenCode reads the persisted session model from opencode.db
- Gemini intentionally returns its default because the CLI does not
provide a reliable active-session lookup
Keep the returned shape intentionally minimal ({ model }). The goal is
to expose only what downstream command consumers need and avoid leaking
provider-specific metadata into a shared transport shape that would
create extra UI coupling and future cleanup cost.
Also make command behavior session-aware: when there is no concrete
session id, do not spawn provider processes or inspect provider session
storage just to answer /models, /cost, or /status. In a new-session
view the correct answer is simply the provider default, and doing more
work there adds latency and unnecessary side effects for no user value.
As part of this, centralize two supporting concerns:
- add a shared helper for building the default current-model result from
a provider catalog so fallbacks stay aligned with DEFAULT
- move leaf-directory validation into shared utils so Cursor session
readers and model lookup code enforce the same path-safety rule
Tests were expanded to cover both the new service delegation path and
the sessionless command behavior, while keeping cache-sensitive tests
isolated from persisted host cache state.
Why this change:
- command output should reflect the model actually driving a session
- new-session views should stay fast and side-effect free
- provider-specific active-model lookup should not be scattered across
routes or UI code
- fallback behavior should be explicit, consistent, and limited to the
provider default when no true active model can be resolved
* feat: support session-scoped model overrides
Model selection was acting like a provider-level preference.
That made resumed sessions drift back to a default or request-time model.
Users expect /models changes made inside a conversation to affect that session.
Store explicit session choices in app-owned ~/.cloudcli state.
This avoids editing provider transcripts or native provider config.
Resolve the effective model before launching each provider runtime.
Claude, Cursor, Codex, Gemini, and OpenCode now honor stored resume choices.
Expose a backend active-model change endpoint for existing sessions.
The models modal can now distinguish default changes from session overrides.
It also shows when a selected model will apply on the next response.
For Claude, stop probing active model state by resuming with a dummy prompt.
Read the indexed JSONL transcript from the end instead.
This preserves provider history while honoring /model stdout or model fields.
Add service tests for adapter delegation and resume-model precedence.
The tests keep cache state, override state, and requested fallback separate.
* feat: make command modal more compact
* fix: preserve opencode session creation events
OpenCode emits the real session id asynchronously on its first JSON output. The runner
registered that id from a helper that could not see the spawned process because
the process reference was scoped inside the model-resolution callback. That
ReferenceError was swallowed by the generic JSON parse fallback, so the client
never received session_created. Without that event, a new OpenCode chat stayed
on / and the assistant stream was not attached to the new session view.
Keep the process reference in the outer spawn scope so registration can update
the active-process map and websocket writer as soon as OpenCode announces the
session id. Split JSON parsing from event processing so malformed non-JSON
output can still stream as raw text, while registration or adapter failures are
surfaced as real errors instead of being hidden as assistant content.
Add a fake opencode executable regression test to lock in the expected lifecycle
ordering: session_created must be sent before live assistant messages, and the
same session id must carry through stream_end and complete.
* fix: clarify model refresh and onboarding providers
OpenCode is now a supported chat provider, but first-run onboarding still only offered
Claude, Cursor, Codex, and Gemini. That made OpenCode harder to discover and
forced users to finish setup before finding the provider in settings or chat.
Adding it to onboarding keeps first-run setup aligned with the providers the
application already supports elsewhere.
The model refresh control was also doing too much visual work. In the new chat
model picker, the previous Hard Refresh label looked like the dialog heading,
which made the primary task unclear. Users open that dialog to choose a model;
refreshing catalogs is only a secondary maintenance action for stale cached
provider model lists.
Rename and reposition the refresh affordance so the model picker reads as a
model picker first. The copy now explains why catalogs are cached, when a refresh
is useful, and that the refresh checks every provider. The /models modal gets the
same clarification so both model-selection surfaces describe the cache behavior
consistently.
* fix: format opencode model catalog labels
OpenCode returns provider-prefixed ids directly from the CLI. Passing those ids through as
labels made the model picker hard to scan: users saw values like
anthropic/claude-3-5-sonnet-20241022 or lowercased, hyphen-split text instead
of readable model names.
Keep the exact OpenCode id as the option value because that is what the CLI
expects, but derive a presentation label for the frontend. The formatter is
intentionally generic rather than a catalog of known providers. It handles common
identifier structure such as provider/model, hyphen-delimited words, v-prefixed
versions, adjacent numeric version tokens, and 8-digit date suffixes.
This keeps OpenCode usable as its model list expands across many upstream
providers without requiring code changes for every new provider or model family.
The description keeps the raw provider-prefixed id visible so users can still
confirm the precise model being selected.
* feat: add more fallback models for cursor
* docs: move model catalog out of shared
The model catalog is no longer a frontend/backend runtime contract.
Keeping it under shared made ownership misleading. It implied the catalog was
application code shared by runtime consumers, even though it now only supports
README links and public API documentation.
Move the catalog into public so it lives beside the docs surfaces that need it.
This gives the API docs a stable, served module and gives README readers a
linkable source without suggesting frontend or backend runtime dependency.
Render the API docs model list from the exported provider registry instead of a
hardcoded Claude/Cursor/Codex subset. That keeps Gemini and OpenCode visible and
makes future provider documentation changes flow through one docs-specific file.
Update README links, provider maintenance notes, and package files so published
artifacts include the standalone docs page and model catalog without relying on
the old shared path.
* fix: simplify empty-state model selector
Keep the provider empty state focused on the setup action users need there:
choosing a model.
The refresh control, cache timestamp, and refresh explanation made the dialog feel
like a cache-management surface.
That extra action is out of place in the empty state, where the goal is to start
a chat with the selected provider and model.
Remove the refresh-specific UI from ProviderSelectionEmptyState and drop the
now-unused refresh/cache props from the ChatMessagesPane pass-through.
Refresh behavior remains available in the dedicated command result flow.
This package has moved to
@cloudcli-ai/cloudclinpm install -g @cloudcli-ai/cloudcliThis package (
@siteboon/claude-code-ui) is now a thin wrapper that installs the new package automatically. For new installations, use@cloudcli-ai/cloudclidirectly.
Cloud CLI (aka Claude Code UI)
A desktop and mobile UI for Claude Code, Cursor CLI, Codex, and Gemini-CLI.
Use it locally or remotely to view your active projects and sessions from everywhere.
CloudCLI Cloud · Documentation · Discord · Bug Reports · Contributing
Screenshots
Desktop View
Main interface showing project overview and chat |
Mobile Experience
Responsive mobile design with touch navigation |
CLI Selection
Select between Claude Code, Gemini, Cursor CLI and Codex |
|
Features
- Responsive Design - Works seamlessly across desktop, tablet, and mobile so you can also use Agents from mobile
- Interactive Chat Interface - Built-in chat interface for seamless communication with the Agents
- Integrated Shell Terminal - Direct access to the Agents CLI through built-in shell functionality
- File Explorer - Interactive file tree with syntax highlighting and live editing
- Git Explorer - View, stage and commit your changes. You can also switch branches
- Session Management - Resume conversations, manage multiple sessions, and track history
- Plugin System - Extend CloudCLI with custom plugins — add new tabs, backend services, and integrations. Build your own →
- TaskMaster AI Integration (Optional) - Advanced project management with AI-powered task planning, PRD parsing, and workflow automation
- Model Compatibility - Works with Claude, GPT, and Gemini model families (see
public/modelConstants.jsfor the full list of supported models)
Quick Start
CloudCLI Cloud (Recommended)
The fastest way to get started — no local setup required. Get a fully managed, containerized development environment accessible from the web, mobile app, API, or your favorite IDE.
Get started with CloudCLI Cloud
Self-Hosted (Open source)
Try CloudCLI UI instantly with npx (requires Node.js v22+):
npx @cloudcli-ai/cloudcli
Or install globally for regular use:
npm install -g @cloudcli-ai/cloudcli
cloudcli
Open http://localhost:3001 — all your existing sessions are discovered automatically.
Visit the documentation → for more full configuration options, PM2, remote server setup and more
Which option is right for you?
CloudCLI UI is the open source UI layer that powers CloudCLI Cloud. You can self-host it on your own machine, or use CloudCLI Cloud which builds on top of it with a full managed cloud environment, team features, and deeper integrations.
| CloudCLI UI (Self-hosted) | CloudCLI Cloud | |
|---|---|---|
| Best for | Developers who want a full UI for local agent sessions on their own machine | Teams and developers who want agents running in the cloud, accessible from anywhere |
| How you access it | Browser via [yourip]:port |
Browser, any IDE, REST API, n8n |
| Setup | npx @cloudcli-ai/cloudcli |
No setup required |
| Machine needs to stay on | Yes | No |
| Mobile access | Any browser on your network | Any device, native app coming |
| Sessions available | All sessions auto-discovered from ~/.claude |
All sessions within your cloud environment |
| Agents supported | Claude Code, Cursor CLI, Codex, Gemini CLI | Claude Code, Cursor CLI, Codex, Gemini CLI |
| File explorer and Git | Yes, built into the UI | Yes, built into the UI |
| MCP configuration | Managed via UI, synced with your local ~/.claude config |
Managed via UI |
| IDE access | Your local IDE | Any IDE connected to your cloud environment |
| REST API | Yes | Yes |
| n8n node | No | Yes |
| Team sharing | No | Yes |
| Platform cost | Free, open source | Starts at $7/month |
Both options use your own AI subscriptions (Claude, Cursor, etc.) — CloudCLI provides the environment, not the AI.
Security & Tools Configuration
Important Notice: All Claude Code tools are disabled by default. This prevents potentially harmful operations from running automatically.
Enabling Tools
To use Claude Code's full functionality, you'll need to manually enable tools:
- Open Tools Settings - Click the gear icon in the sidebar
- Enable Selectively - Turn on only the tools you need
- Apply Settings - Your preferences are saved locally
Recommended approach: Start with basic tools enabled and add more as needed. You can always adjust these settings later.
Plugins
CloudCLI has a plugin system that lets you add custom tabs with their own frontend UI and optional Node.js backend. Install plugins from git repos directly in Settings > Plugins, or build your own.
Available Plugins
| Plugin | Description |
|---|---|
| Project Stats | Shows file counts, lines of code, file-type breakdown, largest files, and recently modified files for your current project |
| Web Terminal | Full xterm.js terminal with multi-tab support |
Build Your Own
Plugin Starter Template → — fork this repo to create your own plugin. It includes a working example with frontend rendering, live context updates, and RPC communication to a backend server.
Plugin Documentation → — full guide to the plugin API, manifest format, security model, and more.
FAQ
How is this different from Claude Code Remote Control?
Claude Code Remote Control lets you send messages to a session already running in your local terminal. Your machine has to stay on, your terminal has to stay open, and sessions time out after roughly 10 minutes without a network connection.
CloudCLI UI and CloudCLI Cloud extend Claude Code rather than sit alongside it — your MCP servers, permissions, settings, and sessions are the exact same ones Claude Code uses natively. Nothing is duplicated or managed separately.
Here's what that means in practice:
- All your sessions, not just one — CloudCLI UI auto-discovers every session from your
~/.claudefolder. Remote Control only exposes the single active session to make it available in the Claude mobile app. - Your settings are your settings — MCP servers, tool permissions, and project config you change in CloudCLI UI are written directly to your Claude Code config and take effect immediately, and vice versa.
- Works with more agents — Claude Code, Cursor CLI, Codex, and Gemini CLI, not just Claude Code.
- Full UI, not just a chat window — file explorer, Git integration, MCP management, and a shell terminal are all built in.
- CloudCLI Cloud runs in the cloud — close your laptop, the agent keeps running. No terminal to babysit, no machine to keep awake.
Do I need to pay for an AI subscription separately?
Yes. CloudCLI provides the environment, not the AI. You bring your own Claude, Cursor, Codex, or Gemini subscription. CloudCLI Cloud starts at $7/month for the hosted environment on top of that.
Can I use CloudCLI UI on my phone?
Yes. For self-hosted, run the server on your machine and open [yourip]:port in any browser on your network. For CloudCLI Cloud, open it from any device — no VPN, no port forwarding, no setup. A native app is also in the works.
Will changes I make in the UI affect my local Claude Code setup?
Yes, for self-hosted. CloudCLI UI reads from and writes to the same ~/.claude config that Claude Code uses natively. MCP servers you add via the UI show up in Claude Code immediately and vice versa.
Community & Support
- Documentation — installation, configuration, features, and troubleshooting
- Discord — get help and connect with other users
- GitHub Issues — bug reports and feature requests
- Contributing Guide — how to contribute to the project
License
GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later) — see LICENSE for the full text, including additional terms under Section 7.
This project is open source and free to use, modify, and distribute under the AGPL-3.0-or-later license. If you modify this software and run it as a network service, you must make your modified source code available to users of that service.
CloudCLI UI - (https://cloudcli.ai).
Acknowledgments
Built With
- Claude Code - Anthropic's official CLI
- Cursor CLI - Cursor's official CLI
- Codex - OpenAI Codex
- Gemini-CLI - Google Gemini CLI
- React - User interface library
- Vite - Fast build tool and dev server
- Tailwind CSS - Utility-first CSS framework
- CodeMirror - Advanced code editor
- TaskMaster AI (Optional) - AI-powered project management and task planning