Introducing idapt Code
idapt Code is a curated skill that lets a normal idapt chat read a project, change it, run its tests, and deliver the result on a computer you pick. As of July 2026 it is live for every account: open idapt Code, choose Start coding, and give the agent a machine, a path, and an outcome.
A first message that needs no follow-up questions looks like this:
On my workstation computer, in ~/work/checkout-api: the payment-retry test fails. Find why, fix it, run the package's tests, and show me the diff.
Nothing new to learn
There is no separate coding app, no repository picker, no provider connection screen. The workflow is assembled from parts of idapt you already have:
- Chat carries the conversation, the model picker, the history, the tool results, and subagents.
- Computers provide a real shell and filesystem, on hardware you pair or a cloud computer you launch.
- Skills carry the playbook: confirm the environment, read the repository's own instructions, preserve work already in the tree, verify, then report.
- Secrets hand a credential to one command by name.
- Tunnels put a running dev server behind a temporary HTTPS URL for review.
The quickstart runs the whole path end to end.
Your machine or ours
Pair a development machine when the checkout, toolchain, and Git configuration already live there. The agent works through the daemon as an allowed operating-system user, reusing the SDKs, package caches, and credentials already on the box.
Create a cloud computer when the task should stay away from your everyday workstation: an unfamiliar repository, a long dependency install, or a job that should keep running after you close the tab.
Connected is not the same as trusted
A computer you pair starts with its sensitive capabilities off. Coding needs exactly two, and you turn them on from the machine itself:
idapt-computer service policy enable remote-shell
idapt-computer service policy enable remote-files
That is a narrower grant than full-control, which also hands over admin operations and desktop control. The skill never changes that policy: when something is blocked it names the capability and stops, so the decision stays on the host. Use idapt Code safely covers how to choose the machine.
The model is not the workflow
The skill defines the development loop, not the model behind it. Use a hosted model, a workspace provider connection, or a compatible local model on the paired machine, and switch on a later turn without moving the task anywhere.
Coding quality, tool use, context, latency, and price still vary between models. Browse the model directory, pick for the task, and let the project's tests be the judge.
Git stays ordinary Git
The agent uses git and an installed gh or glab on the selected computer. It inspects the worktree, creates a branch, shows the diff, runs the checks, commits, pushes, and opens a pull request when you ask for that step.
Existing credential helpers keep working. When a task needs a token that should not live on the machine, put it in Secrets and refer to it by name.
Good to know
- There is no dedicated diff-review pane or worktree manager. Ask the agent for the diff, and for a
git worktreewhen a task needs one. - VS Code Server is optional. The agent works through the shell and filesystem; a browser editor is for you, not for it.
- A command reaches everything its operating-system user reaches. Use a development account or a cloud computer for anything unfamiliar.
- Claude Code and Codex remain the better fit if you want a coding-first terminal and IDE harness around one model family. The Claude Code and OpenAI Codex comparisons say where each one wins.
Start with one bounded task
Pick a failing test, name the computer and the path, and ask for the diff. For a longer run that ends with a live URL, follow From Prompt to Deployed Site on a Cloud Computer.
Found this helpful? Share it: