CodeWebChat: let a coding agent find your files, then let a chatbot write the code

The workflow is four steps and two tools

The Introduction section states a workflow in four numbered steps. Type your instructions. Run Agentic Search to get task-relevant context files. Select examples for model guidance. Then send the prompt with a chatbot or an API call, and the send step splits into two modes: EDIT for multi-file changes in a single response, and ASK for general help in a conversation.

The README attaches a number to this approach, claiming a workflow that is 10X faster at one-tenth the cost of coding with agents alone. That is the project's own claim and there is no benchmark in the repository to support it. What is verifiable is the mechanism underneath it, which is that no session accumulates. The README puts it as zero ever-growing sessions and shorter thinking for the same or higher output quality.

That design choice has a second motivation buried in the Efficiency and speed list: for the Agentic Search prompt specifically, state-of-the-art models offer diminishing returns over mid-tier ones. If the search step is the one that reads your whole repository, you do not want to run it on the most expensive model available. The project is betting that you can use a cheap model to decide which files matter and an expensive model to write the change.

Two supporting directories sit alongside the prompts. There is a `docs/` directory and a `PRIVACY.md`, and the repository is a pnpm workspace with `apps/` and `packages/` under the root `package.json`, plus a `.husky/` directory and Jest configuration at the root. The root manifest is named `cwc`, which is the abbreviation the README uses for the extension throughout.

Agentic Search shells out to seven CLIs

The Agentic Search prompt is described as task-relevant files from your favourite coding agent, using that agent's one-off headless mode. Seven CLIs are listed as supported: Antigravity, Claude Code, Codex, Cursor, Grok Build, Muse Code and OpenCode.

That list is the single most useful thing in the README for deciding whether the extension fits your setup, and it is worth reading carefully because it is about agents rather than chatbots. The distinction matters: this step is not asking a model to write code, it is asking one to sort your repository. The prompt template that gets sent is deliberately narrow:

# Task

In the project, find the complete set of primary and structural files relevant to the query.

# Output formatting

Output strictly as a bulleted list of file paths without explanations or any other text (e.g., - `path/to/file.ext`).

# Query

[INSTRUCTIONS]

The output format instruction is doing real work. By demanding a bare bulleted list of paths with no prose, the extension gets something it can parse, and by refusing explanations it makes it cheaper for the model to comply. There is also an Intelligent Search variant that takes attached files rather than shelling out, and it offers both a WEB flavour that asks for a short explanation after the list and an API flavour that forbids it.

Those two variants exist because they go to different destinations. The WEB version is for pasting into a chat window, where you want to see why each file was picked. The API version is for a program, where extra tokens are waste.

Seven prompt templates for the tasks you actually repeat

The Prompts section is the bulk of the README, and it is a catalogue of small templates rather than prose. Each one lives in a collapsible block with a WEB or API variant.

Asking is the minimal template, three fields: Files, Task, Instructions. Editing adds an Output formatting section that requires the model to announce every new, updated, renamed or deleted file as a markdown heading, then print original and updated snippets using Git-style merge conflict syntax. That formatting requirement is what lets a human apply a multi-file change by reading diffs rather than by re-reading whole files.

Code at cursor is the tab-completion path, and it is the most precisely specified template in the set. The WEB variant wants a heading in the exact form `### Code at cursor: path (ROW:COL)`, a code block with the replacement, and an explanation, and it instructs the model to always call the placeholder the cursor position and the output the completion. The API variant drops all of that and asks only for replacement text inside `replacement` XML tags with no explanation at all. Two prompt shapes for one feature, one optimised for a person and one for a parser.

The remaining three are repair and bookkeeping. Patch repair takes an original file plus malformed edits and asks for the corrected file under a fixed heading, `### Patch repair: path`. Commit messages take the staged changes plus the context files that were in play when edits were accepted, and ask for a single imperative sentence with no markdown and no trailing dot. That last constraint is a small piece of engineering taste: the output goes straight into a commit message.

One more mechanism is described near the end of the Prompts section. CWC orders context files by modification and selection recency, and combines that with placing the instructions at the very end of the message. Ordering by recency front-loads the files you touched most recently, which is a cheap way to spend a context window well.

A free extension with no licence file

Two facts about this repository deserve to sit side by side, because they are both true and neither resolves the other.

The README describes CWC as a free and privacy-first AI coding toolkit for VS Code, and the privacy claim is absolute: it operates 100% on your machine, with no code, prompts or usage data collected. A dedicated `PRIVACY.md` file at the root backs that up as a document rather than a bullet point. Nothing about that claim is hard to believe, either. An extension that shells out to CLIs you already installed and sends prompts to a chatbot you already have has nowhere to send telemetry that would mean anything.

Against that, the repository has no `LICENSE` file. The tree lists `.gitignore`, `.github/`, `.husky/`, `.nvmrc`, `.prettierrc`, `.vscode/`, `.vscodeignore`, `PRIVACY.md`, `README.md`, `apps/`, `docs/`, `jest.config.js`, `media/`, `package.json`, `packages/`, `pnpm-lock.yaml`, `pnpm-workspace.yaml` and `tsconfig.json`, and licence is not among them. GitHub's own licence detection also returns nothing for this repository, so there is no fallback to read.

Free to use and open source are different claims, and only the first one is documented. For personal use that is a distinction without much consequence. If you want to fork it, read `PRIVACY.md`, check the Marketplace listing, and ask the author, because the terms are not stated anywhere in the repository.

Two smaller naming details are worth carrying in your head. The extension publishes under the identifier `robertpiosik.gemini-coder` in the Visual Studio Marketplace and `robertpiosik/gemini-coder` on Open VSX, which has nothing to do with either the repository name or the abbreviation CWC. And the default branch is `dev`, not `main`.

Where it sits against agent mode

The honest comparison is with the agent mode in Cursor, Claude Code or Codex, which is exactly what the README positions itself against.

Agent mode keeps a conversation alive and lets the model call tools: read a file, run a test, try again. That is genuinely more capable for work where the right next step is not known in advance. It is also why agent sessions get expensive and slow, since every turn can accumulate more context and more tool calls than the task needs.

CWC's approach gives up autonomy deliberately. You decide what to work on, the agent runs once to propose a file set, you correct that set by hand, and only then does a model write anything. Nothing iterates on its own. In exchange you get three things agent mode does not offer: the file set is visible and editable before you spend anything, there is no session to grow stale, and you can use a cheap model for the search and an expensive one for the edit.

That trade is a bad one for a task like fixing a failing test where the failing file is not obvious, since a wrong file list dooms the answer regardless of model quality. It is a good one for a refactor with a known blast radius, a review comment on a specific function, or a commit message. The Predict-the-file-list step is the whole product, and it is worth judging on how often you have to correct it.

Engineering hygiene in the repository is ordinary and unremarkable: pnpm 10.10.0, TypeScript 5.8.3, Jest 29 with ts-jest, Prettier run through lint-staged on TypeScript, JSON, CSS, SCSS and Markdown files, and Husky wired as a preinstall hook. The last push was on 2026-09-20.

Editorial conclusion

CodeWebChat is the right shape of tool if you already use two different AI clients and dislike paying a frontier model to re-read a repository on every turn. Its whole argument is that context selection is a search problem and generation is not, so separating them lets a cheap model do the indexing and an expensive one do the writing. Two things to settle before installing. The extension publishes under the identifier `robertpiosik.gemini-coder` in both the VS Code Marketplace and Open VSX, which has nothing to do with the repository name, so search for that identifier rather than the project name. And there is no licence file in the repository, which leaves reuse terms unstated even though the extension is described as free. Install it, run one Agentic Search prompt against a repository you know well, and compare the file list against what you would have picked by hand.

Frequently asked questions

Official sources

1. Issues
2. README
3. robertpiosik/CodeWebChat on GitHub