aico in VS Code

A tab of its own in the Secondary Side Bar, beside Chat. Drawn natively, styled from your theme's own colours, and aware of what you have open — not the web workspace in an iframe.

Install it

The extension needs aico on your PATH and Node 22.5+. It is not on the Marketplace yet, so install the packaged build:

npm install -g @suhail-akhtar/aico
code --install-extension aico-vscode-0.6.0.vsix

The .vsix is attached to each release. Reload the window afterwards — an editor that was already open predates the extension and has not loaded it, which from the inside is indistinguishable from a broken install. If a keypress does nothing, run aico: Check the Setup from the command palette; it reports the version, the folder, the server and the command it would run.

aico needs a folder open. A session's log is filed under one and its file tools are confined to it, so an empty window offers you a folder picker rather than a chat box.

The server still owns the run

Closing the panel, or the whole window, does not stop the work. The extension does not reimplement the engine — it starts aico serve for the folder you have open and talks to it. Reopen the panel and the session replays from its event log, and it is the same session you can pick up in a browser tab.

The webview never sees the server or its token. Every request is tunnelled through the extension host, which is what lets the panel be a plain UI rather than a browser page that happens to be hosted in an editor.

It knows what you are looking at

The active file, your selection with its line range, and that file's Problems arrive as chips above the composer. Every chip is removable, and a removal sticks — so what gets sent is on screen before you send it.

• # points at another file or a workspace symbol.
• @ addresses a specialist agent for the rest of the session.
• Ctrl+Alt+A puts the cursor in the composer with the selection already attached.

The rule behind the chips: inline what nothing else can recover — a selection, a language server's diagnostics — and merely name files, because aico has Read and can fetch exactly the part that matters. Getting that backwards is how an editor integration sends fifteen thousand tokens of open tabs with every "hello".

Edits land in the editor

A write is applied as a WorkspaceEdit, not written behind VS Code's back. So Ctrl+Z takes it back, Source Control shows it, and the file opens where it changed.

Declining one is a real answer. The tool call fails, the agent is told why, and it takes another route — rather than carrying on believing it wrote a file that is not there.

Approve as much or as little as you like

Prompts are native modals rather than cards in the panel — a card can be scrolled past while the turn sits blocked on it. Terminal is deliberately not in the middle mode's pass-through list: a shell command can do everything a file write can and more, so "auto-accept edits" would be a lie if it also ran commands.

The editor as a tool

Three things the engine cannot do from outside VS Code, which it can do from inside it. They are offered only while an editor is attached — the same conversation opened in a browser tab has none, and a tool that can only answer "there is no editor here" costs a turn to discover.

VSCodeDiagnostics works in Plan mode too, because "what is already broken here?" is the first question of most plans and the language server answers it better than a grep. Adding a workspace folder or opening one always confirms first, whatever the approval mode says — opening a folder replaces the window.

There is deliberately no "run any VS Code command" tool: that surface reaches deleting files and installing extensions, and no permission prompt can describe it honestly. There is no editor terminal either — commands run on aico's own shell, which is visible in the transcript and identical on every surface.

Windows gets a shell whose commands exist

The tool a model sees is called Bash, so it writes ls and head. Running those through cmd.exe returns 'ls' is not recognized and the run burns turns rediscovering it. aico prefers Git Bash, then PowerShell, then cmd — and the prompt names which one it picked. AICO_SHELL overrides.

The shape of a run, on screen

• Task list — collapses to one line once resolved, and never claims all done for a list finished by cancelling half of it.
• Delegation — a strip of sub-agents that collapses when they finish and stays open when one fails.
• Plans — Go ahead, Amend, Later, Decline. The wording sent is the same the browser client uses, so a plan agreed in the editor still reads as agreed when the log replays in a tab.
• Context meter — how much of the window is spent, with auto-compaction when it fills.
• Goal — one standing objective, pinned above the composer where it is read.

Messages can be copied, rated, branched from, and edited and sent again with arrows to move between versions. The conversation itself can be renamed in place, forked, or archived from the ⋯ menu.

Settings: basic here, the rest on the web

The model and the active provider are switchable from the composer. Keys, endpoints, MCP servers, skills, memory and agents are a form and a pasted secret — a 300px column does neither well — so Settings in the ⋯ menu opens the web workspace straight onto them. VS Code's own settings hold the extension's behaviour:

Two surfaces, one core

The panel is not a second product. The state layer — the reducer, the store, the turn projection, plans and task lists — is imported unchanged from the browser client, so a fix to how a failed edit is drawn lands in both. What differs is the view: VS Code gets an editor panel, and the browser gets width, which is what Mini Apps, the trajectory view and the settings screens actually need.