Cloud IDE

Cloud IDE by Clatter Labs is a browser-based, full-stack development environment for creating, editing, running, and testing applications without configuring a local development toolchain.

This guide covers project management, the editor, file operations, Git connectors, runtimes, the terminal, collaboration, and the Radar AI agent, including its operational limits.

1. Overview

Cloud IDE brings the core development workflow into a single workspace:

• Isolated workspaces: Each project has an independent workspace and its own file system.
• Integrated execution: Install dependencies and run development servers directly from the terminal.
• Live Preview: View running web applications inside the editor.
• File synchronization and periodic saving: Keep workspace files up to date as you work.
• AI-assisted development: Use Radar to inspect, create, and modify project files.

Quick start

1. Open Cloud IDE.
2. From the dashboard, select Deploy IDE.
3. Choose a starter template or import a Git repository.
4. Enter a project name and open the workspace.
5. Review the project’s setup instructions and dependency files.
6. Install dependencies and start the application in the terminal.
7. Open Live Preview to inspect the running application.

For a Node.js project with a dev script, a typical workflow is:

npm install
npm run dev

2. Dashboard and Project Management

The dashboard is the entry point for managing your projects and workspaces.

Create a project

Select Deploy IDE to create a workspace. You can:

• Start from a template such as React, Next.js, Vite, Node.js, Python, or Vanilla JavaScript.
• Connect a Git repository to work from an existing codebase.
• Assign a custom project name.

Manage existing projects

The project list displays your active workspaces, including:

• Project name.
• Last modification date.
• Actions to open or delete the project.

Access and privacy

Workspace access is restricted to the project owner and explicitly authorized collaborators. An unauthorized user cannot open a workspace simply by obtaining its URL.

For the invitation workflow, see Collaboration and Forking.

3. IDE Workspace

The workspace combines navigation, code editing, execution, and application preview.

Activity Bar

The Activity Bar provides access to the main workspace panels:

Central editor

The editor supports:

• Multiple tabs for working across several files.
• Syntax highlighting for common languages, including TypeScript, JavaScript, Python, HTML, CSS, JSON, Markdown, and YAML.
• IntelliSense and autocomplete.
• Real-time syntax diagnostics.
• Multi-cursor editing for changing multiple locations at once.

The usefulness of completions and diagnostics depends on the language and the project configuration.

Toolbar

Live Preview

Live Preview displays the application served by the workspace’s development server.

Its navigation controls let you:

• Change the application route.
• Reload the current page.
• Open the preview in a separate browser tab.

Keyboard shortcuts

4. File Explorer and Asset Management

Create files and folders

Use the creation icons above the file tree, or right-click an empty area of the Explorer.

Nested paths are supported. For example, creating:

src/components/Button.tsx

creates the file and any required parent folders.

Rename, duplicate, or delete items

Right-click a file or folder to access:

• Rename
• Duplicate
• Delete

File icons

The Explorer identifies extensions and displays language- or framework-specific icons to make the project structure easier to scan.

Global search

Open Search to search across project contents. Available controls include:

• Project-wide text search and replacement.
• Path exclusions.
• Case-sensitive matching.

Use the editor’s find command when you only need to search the active file.

5. Git Connectors and Repository Import

Connectors import source code from supported Git hosting providers.

Supported providers

• GitHub
• GitLab
• Bitbucket

Prepare access credentials

Create credentials with the minimum permissions needed to read the intended repositories.

Import a repository

1. Open Connectors from the Activity Bar.
2. Select the Git provider.
3. Enter the supported access credential.
4. Select Connect.
5. Browse or search the available repositories. Repository lists support pagination.
6. Choose a repository and branch.
7. Select Clone Repository.

The importer retrieves the repository’s file tree and reconstructs it in the workspace.

Import filtering

To reduce import size and startup time, the importer filters out large non-text files and generated or repository-internal directories such as:

node_modules/
.git/

After import:

• Install dependencies from the project’s package manifest.
• Check that required assets are present.
• Review environment configuration before running the application.

Credential handling

The described connector design keeps access tokens encrypted and temporary within the current local session, using them to communicate with the selected provider’s API rather than persisting them on external servers.

As a developer:

• Never place access tokens in source files, terminal examples, or Radar prompts.
• Use the narrowest supported permissions.
• Revoke credentials that are no longer needed.
• Check current deployment security documentation before connecting sensitive repositories.

6. Runtimes, Build Tools, and Development Servers

JavaScript and TypeScript

Cloud IDE supports Node.js-based development workflows and the following package managers:

• npm
• pnpm
• yarn
• bun

The environment supports workflows built around tools such as esbuild, SWC, Vite, Next.js, and Webpack.

TypeScript and JSX/TSX compilation runs inside the workspace through the project’s configured toolchain; no local toolchain installation is required.

Install and run a Node.js project

For an npm-based project:

npm install
npm run dev

Use the package manager associated with the repository’s lockfile. Avoid switching package managers unintentionally.

Development server lifecycle

1. Run the project’s development command.
2. The server starts on an internal port.
3. Cloud IDE detects the server and routes it to Live Preview.
4. Saved changes are picked up by the project’s development tooling.

Hot Module Replacement (HMR) updates supported parts of the application without a full reload when the framework and server configuration enable it.

Python

Cloud IDE provides a Python environment for running scripts and installing compatible dependencies.

Run a script with the available Python command:

python script.py

Or:

python3 main.py

Projects can declare dependencies in requirements.txt. Where automatic dependency installation is not applied, install them explicitly using the available Python interpreter:

python3 -m pip install -r requirements.txt

Package compatibility depends on the runtime and any required native or system libraries.

7. Terminal

The integrated terminal provides interactive shell access to the workspace.

Multiple sessions

Open multiple terminal tabs to separate tasks, for example:

• Session 1: Development server.
• Session 2: Dependency installation, tests, and build commands.
• Session 3: Radar.

Keeping the development server in its own session makes its logs easier to inspect.

Maximize and restore

Use the terminal’s maximize control to expand it across the editor area. Select the control again to restore the normal layout.

This is useful for reviewing long build output or error logs.

Terminal controls

Clearing the screen does not stop a running process.

8. Radar AI Agent

Radar is an AI coding agent available inside the terminal. It can help write code, investigate errors, and perform file operations in the current project.

Start Radar

In a terminal session, run:

radar

The terminal enters Radar’s input mode:

radar ›

Describe the task, relevant paths, and any restrictions.

For example:

Read src/components/Button.tsx and fix the disabled-state styling.
Do not change other files. Explain the changes when finished.

Available tools

A request to analyze code is different from permission to run commands. State command-execution requirements explicitly.

Operational limits

Continue a multi-step task

If Radar stops after reaching its step limit, enter a follow-up request:

Continue the remaining changes. Keep the same scope and constraints.

Review completed work before continuing. A follow-up starts another bounded sequence; it does not remove the per-request limit.

Exit Radar

To return to the normal shell:

exit

Alternatively, press Ctrl + C.

Recommended workflow

1. Ask Radar to inspect the relevant files.
2. Define a narrow modification scope.
3. Request the change.
4. Review the edited files.
5. Run tests or build checks.
6. Continue with the next task.

For long sessions, repeat important constraints rather than relying on older conversation history.

9. Collaboration and Forking

Share a workspace

1. Select Share Workspace in the toolbar.
2. Enter the invited developer’s email address.
3. The system creates a secured invitation link and notifies the user.
4. The invited user opens the link and accepts the invitation.
5. The user joins the shared workspace with file synchronization.

Users who are not authorized for the project are denied access, even if they have the invitation or workspace URL.

Fork a workspace

Use Fork when you want an independent copy for experimentation or substantial refactoring.

1. Select Fork.
2. Enter a name for the new project.
3. Open the newly created workspace.

The fork contains a copy of the project files and settings and is independent of the original workspace.

Changes in the fork do not modify the original project.

10. Settings and Customization

Open Settings from the Activity Bar.

Saving and formatting behavior can also be adjusted through the available settings.

11. Troubleshooting

Live Preview is blank or shows Connection Refused

1. Check the terminal where the development server should be running.

2. Look for a startup confirmation and local address, such as http://localhost:....

3. If the server stopped, inspect the error and restart it using the project’s command:

   Terminal

   npm run dev

4. Select Reload in Live Preview.

5. Confirm that the preview route exists in the application.

A blank page with a running server may indicate an application error rather than a connection problem. Review server output and browser error messages.

Dependency installation fails

1. Read the first meaningful error in the installation output.
2. Check package.json, the lockfile, and the required runtime version.
3. Use the package manager expected by the project.
4. Resolve incompatible dependency versions where possible.

For an npm peer-dependency conflict, a temporary workaround may be:

npm install --legacy-peer-deps

A repository is missing from Connectors

Check that:

• The credential has not expired or been revoked.
• It belongs to an account with access to the repository.
• Its permissions allow the required repository and API operations.
• Any provider-side organization approval requirements have been satisfied.
• You have checked additional result pages or searched for the repository name.

Imported files or dependencies are missing

The importer filters generated directories and large non-text content.

• Reinstall dependencies from the project manifest.
• Check required assets individually.
• Do not expect .git history or node_modules to be included.

Radar stops during a complex task

Radar may have reached its five-step tool limit.

1. Review the changes already made.
2. Ask it to continue.
3. Restate important requirements if the conversation has become long.
4. Split the remaining work into smaller tasks.

Radar cannot process a file

• Confirm that the file is text, not binary.
• Check whether the file is unusually large.
• Direct Radar to a smaller component or more specific file.
• Avoid assuming that truncated content has been fully inspected.

A development server blocks the Radar workflow

Run the server in a separate, normal terminal session. Use Radar for bounded operations such as inspecting files, applying changes, and executing explicitly requested build or test commands.

Multi-page series generator

Turn a long documentation guide into a structured series of Markdown pages. This workflow uses Cloud IDE and Radar to plan the series, draft pages in small batches, and review navigation and technical accuracy.

The example below organizes the Cloud IDE Developer Documentation into focused pages for setup, development, collaboration, and troubleshooting.

Before You Begin

You need:

• A Cloud IDE workspace.
• The source documentation saved as a text or Markdown file.
• A destination folder for the generated pages.
• Any existing documentation conventions, including filenames, links, and front matter.

Open Cloud IDE, then open or create a project.

Before generating files:

1. Save your current work.
2. Preserve a recoverable copy or use Fork to create an independent workspace.
3. Check the destination folder for files that must not be overwritten.
4. Remove credentials and other sensitive information from the source.

Plan the Series

Define the audience and page boundaries

Organize pages around reader tasks rather than splitting the source into equally sized sections.

For the Cloud IDE guide, use this structure:

Keep warnings beside the procedures they qualify. For example, repository import limitations belong on the repository page, not only in troubleshooting.

Create an outline first

Start Radar in the terminal:

radar

Ask for an outline before requesting page files. Replace the example paths with your own:

Read docs/source/cloud-ide.md.

Propose a multi-page documentation series for developers.
For each page, provide a title, filename, purpose, source sections,
and related pages.

Preserve all technical limits, security warnings, and compatibility notes.
Do not invent features, commands, settings, or product guarantees.
Identify unclear claims for review rather than resolving them by guessing.

Do not modify files or run commands yet.

Review the outline for missing topics, duplicated instructions, and pages that are too broad.

Once approved, save it as a working plan, such as docs/series-plan.md.

Generate the Pages

Use a consistent page structure

Each page should include:

• Purpose: What the reader can accomplish.
• Prerequisites: Required access, files, or running services.
• Instructions: Task-oriented steps and relevant examples.
• Limitations: Warnings and constraints from the source.
• Related pages: Links to the next task or supporting information.

A minimal page pattern is:

## Page Title

Explain the page’s purpose.

### Before you begin

- Required access or setup.

### Complete the task

1. Perform the first action.
2. Verify the result.

<Note>
Include relevant limitations from the source.
</Note>

### Related pages

- [Series overview](index.md)
- [Next topic](next-topic.md)

Use your documentation framework’s established conventions if they differ.

Generate one page at a time

Radar allows up to five consecutive tool steps per request. Reading source material, writing a page, and running a check can each consume separate steps.

Example request:

Read docs/series-plan.md and the relevant sections of
docs/source/cloud-ide.md.

Create only docs/cloud-ide/repository-imports.md.
Do not overwrite an existing file; report it if the path already exists.

Cover supported providers, credential preparation, import steps,
filtering, and credential-handling cautions.

Preserve the distinction between importing source files and creating
a conventional Git clone. Do not imply automatic synchronization
or push-back to the repository.

Use GitHub-flavored Markdown and relative links from the approved plan.
Do not modify other files or run commands.
Report anything left incomplete.

Review the result before requesting the next page.

If Radar stops, inspect the files before continuing:

Continue only the unfinished repository-imports page.
Keep the same scope and constraints.
Do not recreate completed content or modify other files.

Add Navigation

Use the overview page as the series entry point. Include a short description and a linked list of all pages.

Add relevant cross-links where readers need them:

• Link Live Preview instructions to application startup.
• Link repository import completion to dependency installation.
• Link Radar’s command limitations to terminal sessions.
• Link troubleshooting entries back to their main procedures.

Validate the Series

Check technical accuracy

Compare each page with the source. Confirm that it preserves these important distinctions:

• Live Preview requires a running web server.
• Repository import excludes .git and does not imply automatic push-back.
• Periodic saving is not version control.
• Radar’s tool-step allowance is not a file-count allowance.
• Radar cannot read or edit binary files.
• Persistent development servers should run in a normal terminal session.
• Workspace synchronization does not guarantee conflict-free editing.
• Forks are independent of the original workspace.

Check structure and links

Before publishing, verify that:

• Every planned page exists.
• Every relative link resolves to the intended page or heading.
• No source topic or important warning was dropped.
• Examples use the correct project commands and package manager.
• Generated pages contain no invented interface controls or guarantees.
• Shared instructions are consistent across pages.

If the project has documentation checks, inspect its configuration and run the documented commands. Ask Radar explicitly before using its command tool.

Troubleshooting

The series is ready for publication when its pages are complete, its links work, and its technical claims remain faithful to the source.