Kodev documentation

Quickstart#

Connect a repository, open a project chat, and describe the result you want. Include any constraints or checks that matter. Kodev creates a working branch and shows its progress in the conversation.

1. Connect GitHub or GitLab and select a repository.
2. Start a chat with a concrete task.
3. Open Workspace to inspect files, the browser, terminal output, and tests.
4. Review the final diff and evidence before opening a change request.

Follow-ups stay in the same conversation. You can ask for a repair or a more focused check without starting over.

Sessions#

A session ties together the accepted message, branch, run status, events, and output. The timeline includes the agent’s updates and tool activity, so you can see what happened before the final reply.

Sleep holds queued work or pauses a running agent at a model boundary. Resume continues the held work. Stop cancels the run and its active subagents. The chat remains available after a run ends, and a follow-up can continue the task.

A checkpoint records the agent’s compact working context. Repository changes also need their branch or workspace backup; an in-memory process alone is not a durable copy of the work.

Subagents#

The main agent can delegate a specific assignment to a named subagent and keep working while that subagent runs. Its messages, tools, checks, and result appear in the Subagents tab. The main agent can wait for a result, send a follow-up, or stop a child.

General subagents start from a snapshot of the parent’s files. Their later commits merge into the parent checkout when it is clean. A conflict leaves the child branch intact for resolution. The parent still owns final verification; a child’s answer does not by itself prove that the combined result works.

One run can have up to three active children and eight children per execution slice. They share the parent’s model, tool, write, and time budgets. Children do not spawn more agents.

Side Ask#

Use Side Ask for a question that should not interrupt the main run. It reads a snapshot of the checkout taken when the question starts and cannot edit files or run commands. If the live checkout is gone, Kodev may restore a retained workspace backup into an isolated read-only tree. Without a restorable snapshot, it declines the question.

IDE and files#

The Files tab uses Monaco for code editing. It includes highlighting, folding, find and replace, undo and redo, and language support for common web files. Search, definitions, references, file creation, rename, and delete are available through the workspace API.

Text files in the editor are limited to 500 KB. A save includes the file version that was read, so a stale tab cannot silently overwrite a newer change. Editing is disabled while an agent or manual terminal process owns the checkout. Unsaved drafts remain in the page when you switch chats.

Cloud workspace#

The task workspace runs in a Cloudflare Container. It is often called a VM in conversation, but the current runtime is a Linux container rather than a dedicated virtual machine. It contains the repository checkout, a Bash terminal, headed Chromium, and an Xfce desktop.

The checked-in image is based on Node.js 22 and Debian Bookworm slim. The deployment configuration uses the standard-3 container class. It includes Git, ripgrep, Python, browser and desktop utilities, and common build tools. A general subagent gets a Git worktree inside the same task environment, not a separate machine.

Containers can sleep when idle. Branch commits, checkpoints, and durable workspace backups carry work across continuations; a running process or an unpushed disk change is not automatically permanent.

Terminal and browser#

The terminal is a persistent Bash pseudo-terminal. Commands see a TTY, can accept input, and retain shell exports across commands. The panel keeps command history, live output, exit status, and time limits.

The browser opens a real page in headed Chromium. Kodev can navigate, inspect the DOM, interact with controls, and capture screenshots. The Computer tab shows the Linux desktop and supports pointer and keyboard input. You can view the screen while an agent runs; manual input waits until the agent no longer owns execution.

Tests and evidence#

The Tests tab gathers commands, checks, browser observations, screenshots, and recordings made during the task. Each proof belongs to the checkout and behavior it actually tested. After an edit, an earlier pass may no longer describe the current branch.

A command exiting successfully shows that the command ran. It only verifies a requirement when the check exercises that requirement. A skipped check, a running command, or an old screenshot cannot establish completion. For UI work, inspect the affected page and viewport again after a repair.

Review changes#

Open Review changes to read the branch diff before merge. Files are grouped so you can move between related changes and inspect line context. Review findings should refer to the current commit and the evidence behind them. From a finding, you can ask the agent to make a correction and return to the diff.

Change requests#

Kodev can publish the task branch and open or update a pull or merge request. It can use a repository change-request template, target another published branch for stacked work, read review feedback, and inspect remote checks. A missing or failed required check is not a pass.

Knowledge and skills#

Project and account knowledge stores short notes you want the agent to remember. Repository instructions, including nested AGENTS.md files, add guidance from the checkout. Skills package a repeatable procedure; they can accept arguments and restrict a subagent’s tools.

A message beginning with /skill-name can start a matching repository skill. If that name is not in the repository, Kodev can use an installed account skill.

Schedules and automations#

Schedules start a task once or on a recurring cron expression in a selected timezone. Automations respond to configured events such as a webhook, filter the event, and start a task or send a message. Their status and invocation history show what ran.

Integrations#

Repository connections let Kodev clone code, create branches, publish changes, and work with reviews on GitHub and GitLab. The app also has authenticated project, chat, workspace, run, and agent APIs. An inbound MCP endpoint provides access to a subset of Kodev resources.

For a full inventory of product areas, including planned connectors and platform capabilities, see All features.

Architecture#

The web app and Worker API are deployed separately. The Worker handles authentication, project data, dispatch, and runner callbacks. D1 shards hold accounts, projects, chats, run state, and subagent activity. Durable Objects coordinate run supervision, event replay, and capacity. R2 holds larger durable objects such as workspace backups. A queue sends accepted work to the task container.

Runner admission gives each execution a scoped identity before workspace activity starts. Checkpoints and event retries help preserve accepted work through interruption; they do not turn every local test into a production reliability guarantee.

Models and budgets#

The model selector uses a cached catalog of tool-capable text models from OpenRouter. When discovery is unavailable, a saved catalog can keep the selector usable. A listed model ID is not a guarantee of provider uptime, account entitlement, or coding quality.

Runs have model, tool, write, and time budgets. Subagents draw from the same limits. The timeline records usage, but it is not an invoice or a complete billing ledger.

Fullstack Mode#

Turn on Fullstack Mode when creating a project, choose a connected GitHub or GitLab account, and name the new repository. The project opens in a familiar chat layout with the conversation in the middle and an app workspace on the right. Kodev can use its existing subagents, build tools, and browser checks to work from your app description.

When Cloudflare hosting is configured and a successful build includes a deployable artifact, Kodev publishes it to staging for the in-page preview and verifies the deployed app. The project owner can publish that staged build to production or restore an earlier production artifact. Self-service hosting setup and database rollback are not available yet; a successful code run alone does not guarantee a live app.

Up next#

These experiences are being designed for Kodev. They are described in the All features reference alongside the rest of the product.

Live Code

Multiple people will work in the same Kodev IDE with shared presence, cursors, and synchronized code edits. The agent will participate in that shared workspace without overwriting newer human changes.

Send to Cloud

From the IDE, you will be able to transfer the current branch, changes, and task context to a cloud workspace so Kodev can keep working after you leave. The handoff will need a reviewable snapshot and a safe way to reconcile results with newer local work.