Devin AI Windows Setup: Blueprints, Sessions, and Cross-Platform Workflows

Windows sessions consume approximately 9% more usage credits or ACUs compared to equivalent Linux sessions, reflecting the virtualization and licensing overhead of dedicated Windows virtual machine environments. Devin AI Windows support provides a dedicated Windows execution platform configured via declarative blueprints, using Git Bash, Chocolatey package management, and full desktop GUI automation for .NET, WinForms, and cross-platform repositories.

In a default configuration, Devin provisions a containerized Linux instance running Ubuntu. When a repository requires Windows runtimes, Visual Studio build tools, or Windows desktop GUI execution, Devin shifts execution to a dedicated Windows virtual machine. The underlying operating system runs Windows Server, but the interaction surface is standard Git Bash. This architecture provides POSIX shell semantics, allowing developers to execute standard bash scripts, commands, and environment variable exports without rewriting automation routines for PowerShell or Command Prompt.

Understanding the operational boundary between the Git Bash emulation layer and native Windows binaries is essential for stable builds. Git Bash remaps file system paths, translating Windows drive letters into mounted root directories. The primary user profile lives at /c/Users/Administrator, and cloned repositories reside within /c/Users/Administrator/repos/<repo-name>. When Devin executes native tools such as MSBuild or the .NET CLI, the underlying runtime receives Windows paths while the controlling shell operates in POSIX format.

For local terminal interaction with the Devin CLI on Windows host machines, Cognition recommends Windows Terminal version 1.25 or higher, or WezTerm for advanced terminal emulation. Legacy cmd.exe (conhost) is explicitly unsupported and causes rendering and control sequence errors during interactive agent sessions.

The following quick reference summarizes the key environmental differences between default Linux runs and Windows execution environments:

Access to Windows execution environments is managed through organization settings in Devin. Because Windows instances run full hypervisor virtual machines rather than shared Linux worker containers, availability is controlled to ensure compute capacity. Teams adopting Windows builds must verify that their blueprints declare correct execution labels and directory paths before running production agent workflows.

Devin configures build sandboxes using declarative blueprints stored in the repository. A blueprint dictates how the environment initializes, restores dependencies, and executes validation checks. Each blueprint document consists of three primary phases:

1. initialize: Executes once during snapshot creation. This block installs system packages, runtimes, SDKs, and build tooling. Modifications to this phase invalidate previous environment snapshots, prompting Devin to build a fresh machine image before launching subsequent sessions.
2. maintenance: Executes whenever a session starts or resumes. This block restores dependencies, runs package managers, and updates local state.
3. knowledge: Defines operational tasks such as test, build, and lint commands that teach Devin how to interact with the project.

For repositories targeting Windows exclusively, declare runs-on: windows at the root of the blueprint. The following example demonstrates a single-platform Windows blueprint for a Node.js and C++ native module project:

runs-on: windows
initialize:
  - name: "Install Node.js runtime"
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"
  - name: "Install Windows build tools"
    run: |
      choco install visualstudio2022buildtools -y
      choco install python --version=3.12 -y
maintenance: |
  npm install
knowledge:
  - name: lint
    contents: npm run lint
  - name: test
    contents: npm test
  - name: build
    contents: npm run build

Package management on Windows relies on Chocolatey (choco). When executing package installations in the initialize phase, pass the -y flag to confirm non-interactive installation. Automated agent sessions will stall if an installer waits on an interactive command-line confirmation prompt. If a tool requires specific registry keys or system reboots, invoke PowerShell or direct MSI installers via Git Bash.

When a repository supports both Linux and Windows, declaring both targets in a single configuration file requires multi-document YAML syntax. Separate each platform definition using a triple-dash (---) document divider. Each document specifies its own runs-on label and tailored initialization routines:

runs-on: default
initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  apt-get update && apt-get install -y build-essential
maintenance: |
  uv sync
knowledge:
  - name: test
    contents: uv run pytest
---
runs-on: windows
initialize: |
  choco install python --version=3.12 -y
maintenance: |
  uv sync
knowledge:
  - name: test
    contents: uv run pytest

The top-level YAML must be a mapping, not a sequence. Writing configurations as an array of items (such as - runs-on: default followed by - runs-on: windows) causes Devin's build ingestion parser to fail with a schema rejection error: Invalid YAML: each YAML document must be a mapping, not a sequence; use '---' to separate multiple blocks. Each platform block must stand alone as an independent YAML mapping separated by ---.

If your repository runs identical commands across both environments (for example, standard Python package synchronization or JavaScript testing without platform-specific dependencies), you can use the list syntax: runs-on: [default, windows]. Devin will build separate snapshots for each operating system using the shared sequence. However, whenever package managers differ (apt-get versus choco), use multi-document YAML.

Devin Computer Use operates full desktop environments on Windows sessions, enabling GUI testing for Windows-native applications including WPF and WinForms. Unlike headless test runners that evaluate code solely through terminal stdout and exit codes, Computer Use provides the agent with an interactive desktop interface running at 1024 by 768 display resolution.

This graphical interface allows Devin to test desktop software the same way a human quality assurance engineer would. The agent moves the mouse cursor, triggers clicks, inputs keyboard strokes, navigates dialog boxes, and takes screenshots to confirm application behavior. For enterprise engineering teams maintaining Windows Presentation Foundation (WPF), Windows Forms, or WinUI applications, this capability automates end-to-end user interface testing without configuring separate third-party testing suites.

To support .NET and desktop development, Windows blueprints configure the necessary SDKs and build systems:

runs-on: windows
initialize:
  - name: "Install .NET SDK and Desktop Workloads"
    run: |
      choco install dotnet-sdk -y
      choco install visualstudio2022buildtools -y
      choco install visualstudio2022-workload-vctools -y
maintenance: |
  dotnet restore
knowledge:
  - name: build
    contents: dotnet build
  - name: test
    contents: dotnet test
  - name: lint
    contents: dotnet format --verify-no-changes

For legacy C++ and Win32 applications, MSBuild and the Visual Studio Test Console execute directly from the blueprint knowledge commands:

runs-on: windows
initialize:
  - name: "Install Build Tools"
    run: |
      choco install visualstudio2022buildtools -y
      choco install visualstudio2022-workload-vctools -y
maintenance: |
  msbuild /t:Restore MySolution.sln
knowledge:
  - name: build
    contents: msbuild MySolution.sln /p:Configuration=Release
  - name: test
    contents: vstest.console.exe bin/Release/Tests.dll

During interactive sessions, Computer Use operates through a continuous screenshot-action-observation cycle:

1. Screen Capture: Devin captures a screenshot of the active Windows desktop to evaluate rendered visual state.
2. Element Identification: The visual reasoning model identifies interactable UI components, such as menus, buttons, input fields, and tab controls.
3. Action Dispatch: Synthetic mouse clicks, drag operations, or keystrokes execute against the targeted window coordinates.
4. State Verification: A subsequent screenshot captures the updated interface, confirming that the window responded as expected (for instance, validating that a modal opened or a form submitted).
5. Video Recording: Devin records the visual session and provides an annotated video along with pull requests, giving human reviewers visual proof that user flows work properly.

Desktop mode is enabled in organization settings under Browser Interaction. Once active, Devin can launch compiled desktop executables, test complex multi-window workflows, and verify graphical layout changes before opening pull requests.

Coordinate Devin AI artifacts across Windows and Linux

Connect Devin AI to Fast.io workspaces via MCP. Stream Windows binaries, automate test artifact retention, and keep builds versioned across your engineering team. Starts with a 14-day free trial.

Start 14-Day Trial

Developing on Windows through Devin introduces specific operational considerations regarding file system paths, environment secrets, and browser automation. Because the control shell is Git Bash, path resolution follows POSIX conventions rather than traditional DOS drive syntax.

When writing shell commands in blueprints or session instructions, write /c/Users/Administrator instead of C:\Users\Administrator. Cloned repositories reside at /c/Users/Administrator/repos/<repo-name>, and uploaded file attachments land in /c/Users/Administrator/.files/. If a Windows CLI tool requires native Windows backslash paths, use cygpath -w <path> within bash scripts to convert paths dynamically before passing arguments to the executable.

Secrets configured in Devin's organization dashboard inject directly into the Git Bash shell environment as standard environment variables. You reference them using bash syntax ($VARIABLE_NAME). For example, authenticating private package registries during the maintenance phase uses standard export and config commands:

maintenance:
  - name: "Configure Private Registry Authentication"
    run: |
      npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN
      dotnet nuget add source "https://nuget.pkg.github.com/my-org/index.json" --name "GitHub" --username "devin" --password $GITHUB_TOKEN --store-password-in-clear-text

For automated web testing within the Windows desktop environment, Devin runs a dedicated instance of Google Chrome. This browser exposes a Chrome DevTools Protocol (CDP) debugging endpoint on port 29229. While Computer Use handles general visual clicking, complex browser tasks such as OAuth token injection, localStorage manipulation, or batch form entry can be scripted directly with Playwright.

Connecting Playwright to Devin's running Chrome instance allows scripts to manipulate the active browser session without launching duplicate windows:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.connect_over_cdp("http://localhost:29229")
    context = browser.contexts[0]
    page = context.pages[0] if context.pages else context.new_page()
    page.goto("https://example.com/login")
    page.fill('input[name="email"]', "engineer@example.com")
    page.fill('input[name="password"]', "configured-secret-token")
    page.click('button[type="submit"]')
    page.wait_for_url("**/dashboard")
    print("Browser session successfully authenticated")

Because this script connects to Devin's existing Chrome process, cookies, session storage, and authentication tokens persist after the script terminates. Devin can immediately navigate the authenticated web application using Computer Use. Store these browser helper scripts in the repository under .agents/skills/ so Devin can invoke them across sessions.

Managing compute costs requires monitoring session consumption. Because Windows sessions consume approximately 9% more usage credits than Linux sessions, reserve Windows blueprints for repositories that strictly require Windows toolchains. For hybrid repositories with isolated sub-services, structure blueprints with multi-document YAML so that frontend and backend services run on default Linux nodes while Windows desktop clients build on Windows VMs.

Running autonomous software development agents across Windows and Linux environments generates diverse build artifacts: compiled executables (.exe), Windows installer packages (.msi), UI test recording videos, crash dumps, and performance profiling traces. Keeping these outputs organized, accessible, and auditable across an engineering team presents a significant coordination challenge.

Local file storage traps artifacts on individual developer machines, while basic object stores like Amazon S3 lack search indexing, metadata structures, and human-friendly preview interfaces. Consumer cloud drives such as Google Drive or Dropbox are designed for manual human synchronization; when autonomous agents perform rapid, concurrent file writes, local sync clients encounter concurrent write collisions and generate duplicate conflict files.

Fast.io provides a dedicated workspace platform designed for agentic development teams. Instead of relying on local desktop synchronization daemons, Fast.io operates as a remote cloud substrate where both human engineers and autonomous agents interact with organization-owned workspaces:

• Model Context Protocol Access: Fast.io exposes remote MCP tools via Streamable HTTP at https://mcp.fast.io/mcp (or authenticated via bearer token at https://mcp.fast.io/mcp/key). Agents connect directly over HTTP without requiring local package installations or custom daemon setups.
• Per-File Version History: Every file uploaded to a Fast.io workspace maintains complete version history. When Devin rebuilds a Windows binary or updates a test recording, prior versions remain fully auditable and restorable, preventing accidental overwrites.
• Intelligence Mode: Enabling Intelligence on a workspace automatically indexes incoming documentation, build manifests, and test logs. Engineers and agents can query the workspace using natural language semantic search with citation-backed responses.
• Metadata Views: Beyond unstructured search, Metadata Views turn workspace files into structured databases. Agents extract typed fields such as build targets, git commit hashes, compiler versions, and test pass rates across binary uploads without manual schema maintenance. Learn more on the Metadata Views page.
• Agent-to-Human Ownership Transfer: Autonomous agents can create workspaces, populate documentation, upload build artifacts, and transfer organization ownership to human engineering leads while maintaining administrative API access.

Fast.io provides predictable subscription tiers for engineering organizations coordinating agent workflows:

Every organization starts with a 14-day free trial, which requires a credit card. Review subscription details on the pricing page and explore technical agent configurations on storage for agents.