How do I run `deno test` or `deno fmt` with Atlas in CI?

To run `deno test` or `deno fmt` with Atlas in CI, ensure the `bash` tool is pre-approved in Atlas's permission configuration. Then, prompt Atlas to execute these commands, for example, `atlas run 'Run deno test and fix any failures.' --format json`. Atlas will use its `bash` tool to invoke the Deno commands.

Can Atlas add JSR dependencies to my Deno project in CI?

Yes, Atlas can add JSR dependencies. With the `bash` and `edit` tools pre-approved, Atlas can execute `deno add jsr:@std/...` and update your `deno.json` import map automatically, just as it would in an interactive session.

What Deno configuration files does Atlas read?

Atlas reads your Deno project's `deno.json` or `deno.jsonc` file. This allows it to understand your import maps, JSR and npm specifiers, and any custom tasks defined within the configuration, ensuring proper integration with your Deno environment.

How does Atlas handle Deno permissions in a headless CI environment?

Atlas aligns with Deno's permission model. In headless CI, you must pre-approve the specific Atlas tools (e.g., `read`, `edit`, `bash`) that correspond to Deno's `--allow-read`, `--allow-write`, or `--allow-run` flags. This prevents interactive prompts and ensures secure execution.

How can I review Atlas's proposed changes to Deno code in CI?

Atlas computes a unified diff for every file edit. When running with `--format json`, these diffs are streamed as part of the event output. Your CI pipeline can capture and display these diffs for review before applying changes, or use them for automated checks.

Can Atlas help tighten Deno's `--allow-all` permissions?

Yes, Atlas can assist. It can analyze your Deno code and suggest how to refine a broad `--allow-all` task down to the specific `--allow-net` and `--allow-read` scopes that the code actually requires, enhancing security within your `deno.json` configuration.

What happens if an Atlas session goes idle in Deno CI?

In its default non-interactive mode, `atlas run` is designed to exit when the session goes idle. This means once Atlas has completed its task, or if it's waiting for input that won't come in a headless environment, it will terminate, allowing your Deno CI pipeline to proceed.

Is it possible to run multiple Atlas subagents in parallel for Deno tasks?

Yes, Atlas fans out work to subagents that can run in parallel background sessions. While `atlas run` focuses on a single prompt, the underlying architecture supports this, allowing for complex Deno tasks to be broken down and executed concurrently by subagents if the prompt implies such a workflow.

Run Atlas Headless in CI with Deno in 2026

To run an Atlas session non-interactively in a Deno CI pipeline and retrieve machine-readable output, use the `atlas run` command with the `--format json` flag. This approach allows Atlas to execute tasks like adding dependencies with `deno add jsr:@std/...` or formatting code with `deno fmt` without human intervention, streaming events directly to stdout for parsing by subsequent pipeline steps. Atlas integrates directly with your `deno.json` configuration, respecting its import maps and tasks.

How do I run Atlas non-interactively in Deno CI?

Running Atlas non-interactively in a Deno CI pipeline is straightforward with `atlas run`, designed for headless execution. By default, it sends a single prompt, streams events to stdout, and exits when the session goes idle, requiring zero human interaction. In 2026, this enables automated code changes and testing within your Deno projects.

The `atlas run` command is purpose-built for CI environments, allowing you to execute Atlas sessions without a terminal interface. For Deno projects, this means Atlas can interact with your codebase, perform actions like running `deno test` or applying `deno fmt`, and then exit cleanly. To initiate a headless session, provide your prompt directly as an argument to `atlas run`. For example, `atlas run 'Refactor the Deno HTTP server to use JSR @std/http.'` will start an Atlas session. Atlas will then draft a plan in its read-only plan agent, execute approved tools, and exit once its task is complete and the session becomes idle. This non-interactive mode is crucial for integrating Atlas into automated Deno workflows, ensuring that code modifications and checks are performed consistently across your development lifecycle.

How do I get machine-readable output from Atlas in Deno CI?

To obtain machine-readable output from Atlas in a Deno CI pipeline, specify the `--format json` flag with `atlas run`. This instructs Atlas to stream raw event data to stdout, rather than human-readable prose, making it easy for subsequent pipeline steps to parse and act upon the session's progress and outcomes. This is essential for automated Deno workflows in 2026.

When integrating Atlas into automated Deno CI, parsing its output programmatically is often necessary. The `--format json` flag transforms Atlas's event stream into a structured JSON format, which can be easily consumed by other tools or scripts in your pipeline. Instead of a TUI or prose, you receive a continuous stream of JSON objects, each representing a distinct event in the Atlas session, such as tool calls, agent state changes, or file modifications. This allows you to build robust automation around Atlas's operations, for instance, by extracting the unified diffs computed for every file edit or monitoring the execution of Deno-specific commands like `deno check`. This structured output is vital for creating sophisticated CI/CD pipelines that react dynamically to Atlas's actions within your Deno project.

How do I configure Deno permissions for headless Atlas runs?

For headless Atlas runs in Deno CI, pre-approving necessary tools and permissions is critical, as there's no human to answer interactive prompts. Atlas integrates with Deno's permission flags, allowing you to explicitly grant access to tools like `bash`, `read`, `edit`, and `todowrite` through its permission configuration. This ensures secure execution, preventing unauthorized actions in your Deno project in 2026.

Atlas's permission-gated tool calls align perfectly with Deno's security model, which uses explicit permission flags. In a headless CI environment, Atlas cannot ask for permission interactively, so all required tools must be pre-approved via its configuration. This means setting `allow`, `ask`, or `deny` rules for tools like `bash` (for running `deno test` or `deno fmt`), `read` (for indexing code or reading `deno.json`), and `edit` (for modifying Deno source files). For example, if Atlas needs to add a dependency, it will use `bash` to run `deno add jsr:@std/...`. Similarly, if it needs to format code, it will execute `deno fmt`. By configuring these permissions upfront, you ensure that Atlas operates within defined boundaries, mirroring Deno's own `--allow-net` or `--allow-read` flags, and maintaining the integrity and security of your Deno codebase.

How does Atlas manage Deno project configuration in CI?

Atlas direct integrates with your Deno project's configuration, reading `deno.json` or `deno.jsonc` files to understand import maps, JSR and npm specifiers, and defined tasks. This allows Atlas to operate within the established Deno ecosystem, ensuring that actions like adding dependencies with `deno add jsr:@std/...` or running `deno test` are consistent with your project's setup. This deep integration is a core feature in 2026.

When Atlas runs in a Deno project, it automatically detects and parses your `deno.json` or `deno.jsonc` configuration file. This enables Atlas to understand your project's module resolution, including JSR and npm package specifiers, and any custom tasks defined within the configuration. For instance, if your `deno.json` defines a task for running tests, Atlas can be instructed to execute `deno test` behind a permission prompt. This capability extends to managing dependencies; Atlas can add new packages using `deno add jsr:@std/...`, updating your import map automatically. Furthermore, Atlas can assist in tightening broad Deno permission flags, suggesting how to refine a general `--allow-all` task down to specific scopes like `--allow-net` or `--allow-read` based on actual code usage, enhancing security within your Deno CI pipeline.

How do I resume or fork an Atlas session in Deno CI?

To resume or fork a prior Atlas session in a Deno CI pipeline, use the `--continue`, `--session`, or `--fork` flags with `atlas run`. This allows a pipeline step to build upon an earlier run, perhaps after a manual review or a failed test, ensuring continuity in complex Deno development workflows. This capability is vital for iterative development and debugging in 2026.

In Deno CI, situations may arise where an Atlas session needs to be continued or branched from a previous state. The `--continue` flag allows you to pick up an existing session from where it left off, preserving its context and any changes made. Alternatively, `--session` lets you specify a particular session ID to load, while `--fork` creates a new session based on an existing one, allowing for parallel experimentation or alternative approaches without altering the original. This is particularly useful when Atlas has made changes to Deno code, and a subsequent CI step needs to verify those changes, or if a human review step is introduced. For example, if Atlas modifies a Deno module and `deno test` fails, you could fork the session to debug the issue, or continue it after a fix has been applied, ensuring efficient iteration within your Deno development pipeline.

Step by step

01Prepare your Deno project: Ensure your Deno project includes a `deno.json` or `deno.jsonc` file, defining your import maps and any relevant tasks.
02Configure Atlas permissions: Pre-approve the necessary Atlas tools (`bash`, `read`, `edit`, `todowrite`) in your Atlas configuration, as headless runs cannot prompt for permissions.
03Invoke Atlas headless: Run Atlas with your prompt and the `--format json` flag: `atlas run 'Refactor Deno HTTP server to use JSR @std/http.' --format json`.
04Set the model explicitly: Specify the model and provider using the GitHub path format, e.g., `atlas run ... --model 'github/provider/model'`.
05Parse machine-readable output: Capture the JSON event stream from stdout in your CI pipeline for programmatic analysis of Atlas's actions, such as unified diffs or `deno test` results.
06Resume or fork sessions (optional): If needed, use `atlas run --continue` or `atlas run --fork <session_id>` to build upon or branch from previous Atlas sessions in your Deno workflow.

Frequently asked questions

How do I run `deno test` or `deno fmt` with Atlas in CI?: To run `deno test` or `deno fmt` with Atlas in CI, ensure the `bash` tool is pre-approved in Atlas's permission configuration. Then, prompt Atlas to execute these commands, for example, `atlas run 'Run deno test and fix any failures.' --format json`. Atlas will use its `bash` tool to invoke the Deno commands.
Can Atlas add JSR dependencies to my Deno project in CI?: Yes, Atlas can add JSR dependencies. With the `bash` and `edit` tools pre-approved, Atlas can execute `deno add jsr:@std/...` and update your `deno.json` import map automatically, just as it would in an interactive session.
What Deno configuration files does Atlas read?: Atlas reads your Deno project's `deno.json` or `deno.jsonc` file. This allows it to understand your import maps, JSR and npm specifiers, and any custom tasks defined within the configuration, ensuring proper integration with your Deno environment.
How does Atlas handle Deno permissions in a headless CI environment?: Atlas aligns with Deno's permission model. In headless CI, you must pre-approve the specific Atlas tools (e.g., `read`, `edit`, `bash`) that correspond to Deno's `--allow-read`, `--allow-write`, or `--allow-run` flags. This prevents interactive prompts and ensures secure execution.
How can I review Atlas's proposed changes to Deno code in CI?: Atlas computes a unified diff for every file edit. When running with `--format json`, these diffs are streamed as part of the event output. Your CI pipeline can capture and display these diffs for review before applying changes, or use them for automated checks.
Can Atlas help tighten Deno's `--allow-all` permissions?: Yes, Atlas can assist. It can analyze your Deno code and suggest how to refine a broad `--allow-all` task down to the specific `--allow-net` and `--allow-read` scopes that the code actually requires, enhancing security within your `deno.json` configuration.
What happens if an Atlas session goes idle in Deno CI?: In its default non-interactive mode, `atlas run` is designed to exit when the session goes idle. This means once Atlas has completed its task, or if it's waiting for input that won't come in a headless environment, it will terminate, allowing your Deno CI pipeline to proceed.
Is it possible to run multiple Atlas subagents in parallel for Deno tasks?: Yes, Atlas fans out work to subagents that can run in parallel background sessions. While `atlas run` focuses on a single prompt, the underlying architecture supports this, allowing for complex Deno tasks to be broken down and executed concurrently by subagents if the prompt implies such a workflow.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related guides

Run Atlas Headless in CI with Atlas (2026 Workflow)

How to run Atlas headless in CI in 2026: atlas run sends one prompt and exits when the session goes idle, with --format json, --command, and --continue for pipeline steps.

Atlas for Deno: Terminal-Native AI Coding in 2026

Atlas is a terminal-native AI coding agent for Deno. Tighten --allow-all down to real permission scopes, add JSR deps, and run deno test and deno check in 2026.

Audit a Deno Repository with Parallel Subagents in Atlas, 2026

Sweep your Deno codebase for issues without context window limits using Atlas's parallel subagents. Leverage deno test, deno fmt, and JSR for efficient, permission-gated audits in 2026.

Refactor a Legacy Deno Module with Atlas in 2026

Safely refactor legacy Deno modules in 2026 without breaking callers. Atlas uses `deno test`, `deno fmt`, and `deno.json` to ensure structural changes preserve behavior and API contracts.

Rename a symbol across the repo in Deno with Atlas in 2026

Refactor Deno code with Atlas to rename functions, classes, or constants across your repository. Atlas uses Deno's LSP for precise renames, ensuring all references are updated, including those in comments and strings

Document a Deno Module with a README in 2026

In 2026, Atlas helps Deno developers generate accurate README documentation directly from source code. Leverage deno test, deno fmt, and JSR with AI-driven code analysis.

Automate GitHub Issue and Pull Request Triage in Deno with Atlas in 2026

Streamline GitHub issue and pull request triage in your Deno projects using Atlas. Leverage Deno's built-in toolchain for secure, permission-gated AI automation directly from GitHub Actions.

Review a Pull Request in Deno with Atlas in 2026

In 2026, Deno developers use Atlas to review pull requests, leveraging its deep understanding of `deno.json` and `deno test`. Catch subtle bugs by examining full file context and verifying changes with Deno's built-in

Browse this resource hub