How to Use JetBrains Air

JetBrains Air lets you start a coding agent inside a JetBrains IDE, give it selected project context, and review its changes where you already navigate and test code. The useful first move is not a sweeping refactor. Install Air Alpha, connect one agent, give it one file and one failing test, then accept nothing until the diff and test result make sense.

The Short Version

Use Air as an agent control room, not as an autocomplete button. The agent does the work, while Air packages the session, passes IDE context, and brings the result back to an IDE-native review surface.

For a first session:

1. Install Air Alpha from the IDE Marketplace.
2. Open a disposable project or branch with a test you can run.
3. Choose a New Session preset and keep Standard Access.
4. Send a first message and complete sign-in if Air asks.
5. Attach the relevant file with @file:.
6. Ask for one small fix and a test.
7. Inspect every changed file in Agent Sessions.
8. Run the test yourself, then keep, edit, commit, or revert the change.

That is the whole useful loop. Everything else, parallel sessions, more agents, organization controls, and cloud handoff, can wait until the loop is trustworthy.

What JetBrains Air Actually Is

Air is the layer between your JetBrains project and one or more coding agents. Think of it as a model-shop inspection bay: an agent brings a proposed part to the table, but the IDE still gives you the measurements, fit checks, and final say.

The September 22 release turned Air into a wider system with three named parts: Air in JetBrains IDEs for individual work, Air Teams for coordination and automation, and Air Governance for policy, visibility, and cost control. This guide stays with the runnable local path, the Air Alpha IDE plugin.

The IDE plugin is not a new foundation model. It can run Codex, Gemini, GitHub Copilot, Claude, and Junie out of the box, and JetBrains says other agents can connect through ACP. ACP, or Agent Client Protocol, is a common socket between an IDE and an agent's complete working machinery, including its tools and model routing.

The current Air IDE page still labels local-to-cloud handoff as coming soon. For a dependable first run, keep the task local and small.

Before You Install It

Air Alpha is a public alpha, not a quiet stable utility. JetBrains warns that the UI and behavior can change and says updates are expected roughly every week. Check compatibility before debugging anything else.

On September 23, 2026, the current Marketplace package for the 2026.2 line was Air 262.8665.463. It supports IntelliJ IDEA 2026.2 through 2026.2.3 and matching 2026.2 releases across the listed JetBrains IDEs. Marketplace also carries builds for the 2026.3 line, so the exact plugin build can differ with your IDE branch.

Compatibility check from this run

IntelliJ IDEA 2026.2.3, build IU-262.10968.63, loaded Air 262.8665.463 in an isolated profile and indexed a disposable Node project without a plugin error. The detected agent was codex-cli 0.153.4, but it was signed out and the host had no graphical session. No interactive Air task, generated diff, or passing agent-written test is claimed here. The UI steps below follow JetBrains' current quickstart and the labels packaged in that plugin build.

How to Use JetBrains Air, Step by Step

1. Install Air Alpha

Open your IDE settings, choose Plugins, switch to Marketplace, search for Air Alpha, and click Install. Restart if the IDE asks.

Air itself is free. The agent behind it may still require an account, subscription, or API billing. If billing is the decision holding you up, Is JetBrains Air Free separates the plugin cost from the agent cost.

2. Open a project with a cheap failure

Start with an existing project you can throw away or reset. A good first task has one relevant file, one observable failure, and one command that proves whether the change worked.

Examples include a slug helper that mishandles repeated spaces, a formatter with one missing edge case, or a small validation function with a failing unit test. Avoid migrations, authentication, deployment code, and broad dependency upgrades on the first run.

Record the baseline before opening a session:

• the current branch or disposable worktree;
• the exact test command;
• whether that test currently passes or fails;
• the files you expect the task to touch.

This turns review into a comparison, not a feeling.

3. Choose a New Session preset

The main toolbar's New Session button starts the currently selected preset. Use its chevron when you want a different preset.

A preset is a saved launch configuration. It chooses the agent and can preselect the model, reasoning effort, access level, and session surface. Air lists agents it detects on the machine alongside built-in presets. If the selected agent is missing, the plugin can prompt you to install it.

For a first task, choose Standard Access. In the current plugin, Standard Access lets the agent read, edit, and run commands inside the project, while access to files outside the project or to the network requires approval. Full Access removes those approval checks for network use and edits anywhere on the machine. That is a poor default for a first session.

4. Send the first message and authorize the agent

Authorization happens when the agent actually needs it. Type a short first message and press Enter. If Air finds credentials the agent already uses on your machine, the session continues. Otherwise it shows Choose a sign-in method to continue.

The available route depends on the agent:

• an agent login can continue in a browser or terminal;
• an eligible JetBrains AI license or organization workspace can supply credits;
• Add an AI provider opens Tools | Air | Accounts for a third-party subscription or API key.

In Accounts, choose More Providers, add the required credentials, use Test Connection, save with OK, then return to the session and select that provider.

Do not paste a secret into the task prompt. Credentials belong in the provider connection flow.

5. Add only the context the task needs

Air can attach files, commits, and skills from the add-context control. You can also type @file: for a file or @folder: for a folder. The distinction matters: attaching one relevant file is like handing a mechanic the faulty component; attaching the whole repository is like emptying the garage onto the workbench.

For the first run, attach the implementation file and name the test command. Add a test file only when the agent needs to understand an existing pattern.

6. Ask for a bounded change with a proof

A useful prompt names the defect, the allowed scope, and the verification command. For example:

Fix repeated whitespace handling in @file:src/slug.js. Add or update the smallest relevant test. Run node --test. Do not change dependencies or touch unrelated files. If the test command cannot run, stop and explain why.

That prompt gives the agent a finish line. “Improve this helper” does not.

7. Follow the session, but do not grade the narration

The agent reports progress and may ask questions. Answer missing requirements, approve only actions you understand, and pay attention to unexpected network requests or files outside the project.

The progress text is useful context, but it is not proof. The proof is the resulting diff plus a test you can repeat.

8. Review the change in Agent Sessions

Open Agent Sessions and expand the completed session. Open a diff for every changed file. The current package includes the actions Show Diff, Generate summary..., and Revert. JetBrains' quickstart says you can keep, edit, commit, or revert the modified files.

Review in this order:

1. Scope: Did only expected files change?
2. Behavior: Does the implementation solve the exact failure?
3. Test quality: Would the new test fail without the fix?
4. Side effects: Did configuration, dependencies, or public interfaces move?
5. Verification: Does the test pass when you run it outside the agent's narration?

If the diff is nearly right, edit it yourself or leave precise feedback for another iteration. If the scope is surprising, revert and restart with a tighter prompt. Do not reward a plausible explanation with a commit.

The Business Math

Air changes the orchestration line item, not the cost of intelligence underneath it. The plugin adds $0 in software spend, while the connected agent can draw from an existing subscription, an API balance, or JetBrains AI credits.

That matters when a team already pays for agents. A second control surface often means another seat before anyone knows whether it improves review. For a public comparison point, GitHub currently lists Copilot Business at $19 per user per month and Enterprise at $39. Ten Business seats are $190 per month before additional usage. Air can connect supported agents without adding an Air plugin fee, but it does not erase the IDE license, provider subscription, API usage, or the human review time.

The practical budget question is therefore narrow: can one free local review surface make existing agent spend easier to direct and verify? Test that with one team and one class of task before buying or standardizing anything else.

Six Use Cases, Ranked by Who Gains Most

1. JetBrains teams already paying for multiple agents

An engineering team with Codex for one workload and Claude for another can start both from the same IDE environment, attach the same project context, and review changed files in one place. The payoff is not cheaper tokens by default. It is less tool switching and a consistent review habit around subscriptions the team already carries.

2. Maintainers clearing small, testable defects

A maintainer can attach the failing helper, describe one regression, require a focused test, and review the resulting diff before it reaches a branch. This pays when the diagnosis is clear but writing the mechanical fix competes with deeper work.

3. Consultants entering an unfamiliar client codebase

A consultant can use the IDE's code navigation to inspect symbols, attach only the relevant files, and ask an agent for a bounded change. Keeping the work inside a disposable branch with Standard Access reduces the chance that unfamiliar repository conventions turn into a sprawling edit. The payoff is faster orientation without pretending the agent understands unstated client rules.

4. QA engineers turning a reproducible bug into a regression test

A QA engineer who can reproduce a bug can attach the implicated file and test area, ask for the smallest regression test, and inspect whether the test truly captures the failure. The value is a shorter handoff from reproduction to a reviewable engineering artifact.

5. Senior developers teaching review through concrete diffs

A senior developer can let an agent propose a small implementation, then walk a newer teammate through scope, assumptions, test design, and revert decisions inside the familiar IDE. The output is not just code. It is a visible review exercise with a real change set.

6. Platform teams comparing agents on the same task

A platform team can run the same bounded task with different presets and compare touched files, test behavior, approvals, and review effort. That produces a more useful evaluation than comparing chat answers, because the unit of judgment is a verified change in the same repository.

Two Products Worth Building Around This

1. A review-evidence sidecar for agent changes

This is the stronger opportunity. Build a small companion that turns an agent session into a review packet: task, attached context, changed files, test command, test result, human decision, and final commit reference. Engineering managers and regulated teams would pay for a clean record that sits above whichever agent produced the code.

The demand is specific enough to matter: ai powered code review platform receives about 1,900 US searches per month, with commercial intent. GitHub's $19 Business and $39 Enterprise seat prices also show that teams already budget for coding assistance and governance.

The smallest sellable version does not need to control the agent. It can ingest a diff and test output, require a reviewer checklist, and export a signed Markdown or JSON record. The catch is platform risk: Air is an alpha, its interfaces can move weekly, and JetBrains may add richer evidence or audit features itself. The moat has to be cross-agent policy and durable reporting, not a thin button inside one IDE.

2. A repo-specific agent setup advisor

Build an onboarding tool that inspects a repository's languages, test commands, sensitive paths, and contribution rules, then recommends a safe first-task template and preset settings. It would sell to teams adopting agents across mixed repositories, where every developer currently repeats the setup work.

The broad demand is large: ai coding assistant receives about 18,100 US searches per month, while ai powered coding agent receives about 8,100. The MVP can be a repository questionnaire plus generated setup notes, bounded starter prompts, and a smoke-test checklist. No deep IDE integration is required at first.

The catch is defensibility. JetBrains, agent vendors, or repository templates can absorb generic setup advice. A viable product needs organization-specific policy checks and evidence that its recommended setup reduces failed or over-scoped changes.

Limits and the Honest Take

Air is most useful when you already prefer a JetBrains IDE and want agent choice without surrendering IDE-native review. It is not a reason to delegate a risky change you cannot verify.

Three constraints matter now:

• It is an alpha. Labels and behavior can change on a roughly weekly release rhythm.
• The plugin is free, the work is not. Agent authorization, subscriptions, API use, IDE licensing, and human review remain separate costs.
• Local is the dependable starting point. The IDE page still describes cloud handoff as coming soon, so do not design your first workflow around closing the laptop while the task continues.

Standard Access also is not read-only. It allows edits and commands inside the project. Use a disposable branch or worktree, inspect the diff, and rerun the test yourself.

The position is simple: Air is worth trying for one small change if JetBrains is already your daily workspace. It is too early to make it the mandatory path for sensitive repositories without a rollback plan, provider policy, and review evidence.

The Monday Move

Pick one bug that has a one-command test. Put it on a disposable branch, install the matching Air Alpha build on one developer machine, choose Standard Access, attach one relevant file, and ask for the smallest fix plus a regression test. Keep the change only if the diff is narrow and the test passes when you run it yourself. That single loop will tell you more than a week of agent demos.

What does JetBrains Air do?

JetBrains Air coordinates coding agents and their context, sessions, and review inside and beyond JetBrains IDEs. In the local IDE plugin, you select an agent, send a task with project context, then inspect the resulting changes in Agent Sessions.

What are the key differences between JetBrains Air and Claude Code?

Claude Code is one coding agent. Air is a multi-agent control and review surface that can run Claude alongside Codex, Junie, GitHub Copilot, Gemini, OpenCode, and ACP-compatible agents, depending on available integrations and authorization.

What is the best IDE for agentic coding?

There is no universal winner. Air is compelling when your team already depends on JetBrains navigation, inspections, and diff tools. The best choice is the environment in which you can constrain, inspect, test, and revert an agent's work reliably.

Is JetBrains free to use?

The Air Alpha plugin is free. Your JetBrains IDE and the agent behind Air may have separate license, subscription, or API costs.

If you want a safe agent workflow built around your repositories and review rules, see AI agent development.