Start here.
Build with context.

Before you start

You need a compatible Windows computer, a Codvian account, and a project folder you are authorized to use. Keep a backup or version-controlled copy before allowing changes. Provider setup depends on whether you use a hosted provider or a local model.

Set up Desktop

1. Install Codvian through the official Microsoft Store destination.
2. Open the application and use its Google sign-in action. Complete the browser flow and return to Desktop.
3. Create a local project and choose the folder for your work.
4. Open provider settings, connect a supported provider or local server, and test the connection.
5. Select a model available to that connection.

BYOK and local models do not bypass Desktop authentication. Model and tool availability may vary by build and account configuration.

Run a small, reviewable task

Start with an inspection request before allowing edits:

Read this project’s README and package scripts.
Explain how to run its tests. Do not change files yet.

Check the response against the project. Then ask for a scoped change with an explicit check. Review the permissions, differences, and verification output before accepting it.

Continue with your first project and permission settings.

Install on Windows

Use the Download page to open the official Codvian Microsoft Store listing. Confirm device requirements and listing availability, then follow the Store installation flow.

This website offers the verified Windows destination. It does not provide a standalone installer or a Linux package. macOS — Coming soon: a Mac version is planned but not yet available.

Complete sign-in

Launch Codvian and choose Google sign-in. The application opens authentication in the browser and waits for the verified session. Return to Desktop after completion. A successful local model connection does not unlock an unauthenticated workspace.

Prepare your project environment

Codvian’s terminal uses the environment available on your computer. Install the tools required by your project, such as its language runtime and Git, using their official instructions. Do not assume Codvian installs project dependencies automatically.

If installation, authentication, or commands fail, see troubleshooting. For the current distributed version and compatibility, use the Store listing and the installed application.

Choose a local project

Use the project control in Desktop to create a new project. Choose Local, enter a project name, and select the folder you intend the agent to work with. Labels can vary between builds.

Choose the repository root rather than an entire drive or broad personal folder. Inspect what files are in scope and remove secrets that do not belong in the project.

Start from a known state

Review existing changes and keep a backup or Git baseline. Tell the agent which files are relevant and which files should remain untouched. Checkpoints are useful recovery tools but do not replace independent backups.

Make the task specific

Inspect the form validation in this project.
Propose a fix for empty input before editing.
Keep unrelated files unchanged.
Add a regression test and run the relevant test command.

Review the approach and requested tool access. After the task, inspect changed files and check which verification commands actually ran.

Connect a supported provider

Open Desktop settings and its provider section. Choose a provider, enter the required credentials or connection information, and run the connection test. Select a model that is available to that account.

Provider connections include OpenAI, Anthropic, Google, OpenRouter, compatible custom services, and local server options. A catalog entry marked as requiring an adapter is not a working connection.

Check model capabilities

A model suitable for chat may not support the structured tool calling needed by an agent. Context size, tool support, provider limits, and available model versions vary. Start with a small task and inspect how it uses tools.

Understand charges and data flow

BYOK requests are billed by your provider. Hosted requests can transmit relevant project context to it. Consult the provider’s own terms, privacy practices, quotas, and usage dashboard.

See BYOK or local model setup. Codvian’s own managed models are paid for with Codvian credits, bought as one-time packs in the dashboard — see pricing.

Prepare the provider account

Obtain an API key through the provider’s official account controls. Confirm that your account has access to the intended model and sufficient quota. A consumer chat subscription does not necessarily include API access.

Configure the connection in Desktop

1. Open the provider section of Desktop settings.
2. Choose a supported provider and enter the key in its credential field.
3. Test the connection and resolve any returned error.
4. Select an available model before starting a task.

Do not paste your key into the chat, repository files, or support form. If you need a custom compatible connection, verify the endpoint with the provider’s official documentation.

Monitor usage and credentials

Your provider sets prices, quotas, model availability, and data handling. Check its billing dashboard for authoritative charges. Provider usage displayed in Codvian depends on what the provider reports.

Revoke or rotate credentials through the provider if necessary, then update the Desktop connection. BYOK is separate from Codvian credits, which pay for Codvian’s own managed models.

Prepare a local model server

Codvian includes local server connection paths for Ollama and LM Studio. Install and configure your chosen server through its official instructions, load a suitable model, and make sure the server is reachable from Desktop.

Hardware, available memory, and model size affect practical performance. Select a model that supports the tool behavior your task needs.

Connect from Desktop

Open provider settings, choose the relevant local server option, confirm the server connection information, and test it. Use the model name supplied by your server. Do not assume that a downloaded model is running or that a chat-only model will handle agent tool calls reliably.

What local does and does not mean

Local inference can keep model processing on the configured machine. Desktop sign-in and other enabled network tools remain separate. Authentication and entitlement requirements still apply.

Check both the project permissions and the model server configuration. See data handling and connection troubleshooting.

Describe the intended outcome

Name the behavior you want, relevant project areas, constraints, and how you will judge completion. Mention any existing work that must remain untouched. Avoid putting credentials or confidential customer data in a prompt.

Ask for a plan when complexity warrants it

For a multi-file change or unfamiliar repository, ask the agent to inspect the project and propose an approach before editing. A plan is a useful checkpoint for scope and assumptions. It is not a separate permission grant for every possible action.

Review the result

Follow tool activity and respond to approval requests. Check the diff and the actual output of tests or builds. A model’s description of success is not enough when a command was unavailable or failed.

Ask it to identify unresolved issues and any checks it could not complete. Use tool guidance and Git review to keep the work inspectable.

Provide relevant attachments

Desktop’s composer supports attachments as task context. Include only material needed for the request and remove private data. Images require a model configuration with image support; not every connected model can interpret them.

Attachments may be included in requests to your selected hosted provider. Review the data you share and the provider’s policies.

Use voice input when available

Desktop includes voice input in the composer. It requires microphone permission and an available transcription configuration. Follow the controls and errors in your installed build, and check the transcript before relying on it as task instructions.

Audio processing may use an external service. Do not assume voice input is offline because your coding model runs locally.

Projects define the workspace

A project identifies the folder for development work. Confirm the active project before submitting a task, especially when moving between repositories. Give the project a recognizable name.

Sessions keep task context

Use a session for a coherent task or conversation. Return to an existing project conversation when you need its context, or start a new one for unrelated work. Check the active project and model when resuming.

Leave a useful review trail

Ask for a short account of changed files, checks run, and remaining problems. Keep code changes in version control and avoid relying on a conversation as your only record of the project.

If the local folder changes or becomes unavailable, restore its expected location or select the appropriate workspace before issuing file actions. For recovery, see Git & checkpoints.

Review approval behavior

Desktop exposes permission choices for how tool actions are approved. Choose the least broad behavior that suits the task. More permissive settings can allow consequential commands to proceed with less intervention.

Read the available choices in your installed build. Ask-first behavior is a useful starting point for an unfamiliar project.

Inspect the requested action

Before allowing a command, consider its working directory, arguments, file effects, and external destinations. Dependency installation, deletion, Git history changes, and interaction with production services deserve particular attention.

Tell the agent explicitly when certain files or operations are outside the task.

Keep review and recovery in the workflow

Permission prompts do not prove an action is correct. Keep version control or backups, inspect changes, and verify results. Do not grant broad access merely to resolve an unclear request.

For public security guidance, see Security & control.

Read and edit project files

The agent can read relevant project content and create or update files within the attached workspace under configured permissions. Ask it to follow existing code patterns and keep unrelated areas unchanged.

Review changed files after execution, including configuration and dependency changes.

Run the project’s commands

Terminal tasks use your local environment. Ask the agent to inspect the project’s documented scripts before choosing commands. Required runtimes, shells, dependencies, and environment variables must be present.

Inspect the project’s scripts and documentation.
Run its existing test and build commands.
Report failed or unavailable checks accurately.

Understand the output

A failing command is evidence that needs interpretation. Review its output and distinguish a code failure from an environment or configuration problem. Do not accept invented test results.

For web projects, browser tools can complement command-line checks when configured.

Use a known repository state

Review Git status before starting a task. Identify your existing edits and tell the agent to preserve unrelated work. If the project is not version-controlled, keep an independent backup before allowing changes.

Review the differences

Ask the agent to inspect the diff and explain how the change satisfies the request. Check configuration, tests, and unexpected file changes as well as the main implementation. Do not assume commits or publishing are implied by a code-editing request.

Treat checkpoints as supplementary recovery

Codvian includes checkpoint support for file snapshots and recovery. Availability and recovery scope depend on the workflow and build. A snapshot may not cover every file, external service, or side effect.

Before restoring, inspect the available state and preserve any work you want to keep. Checkpoints are not a replacement for repository history or backups.

Confirm the browser tool is available

Codvian includes browser tooling for navigation, inspection, and interaction. The browser driver and relevant environment must be configured. If a tool is unavailable, the agent should report the limitation.

Request a focused browser check

For a local web project, first run its documented preview or development command. Ask the agent to open the resulting page, exercise the affected flow, and inspect relevant browser output.

Open the local preview for this change.
Check the form at mobile and desktop widths.
Inspect browser errors and describe any unresolved issue.

Keep browser actions in scope

Browser access can interact with external services and authenticated sessions. Make the permitted destinations and actions clear. Do not use production customer data for ordinary verification.

A browser screenshot alone does not prove all routes or states work. Pair visual inspection with relevant interaction checks and project tests.

Sign-in does not complete

Check your internet connection and finish the Google sign-in flow in the browser. Return to Desktop and read any displayed error. If the application offers cancellation, cancel the pending attempt before retrying. BYOK is not an alternative authentication path.

A provider connection fails

Check credentials, account access, available quota, model name, and endpoint configuration. Run the provider connection test again. For local models, confirm that the server is running and reachable. Do not share your key with support.

A command fails

Read the command output. Confirm that the project folder, runtime, dependencies, and selected shell are correct. Ask the agent to distinguish a missing tool from a code error before making unrelated changes.

Browser verification is unavailable

Confirm that browser tooling is configured in your environment. If it is unavailable, keep that limitation in the final review rather than treating the page as verified.

Contact support

Include the Desktop version, Windows version, steps to reproduce, and the relevant error with sensitive values removed. Use Contact support. Do not include passwords, keys, private source code, or payment-card data.

Codvian basics

Models, free tier and quota

Plans, credits and payments

API keys

Privacy, security and misuse

Getting help