# Run Atlas Headless in CI with Deno in 2026 > Run Atlas headless in Deno CI using `atlas run --format json` to automate tasks and get machine-readable output from your Deno projects. 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. ## Key takeaways - Atlas runs headless in Deno CI using `atlas run` for non-interactive automation. - Obtain machine-readable output by passing `--format json` to `atlas run` in Deno pipelines. - Pre-approve Atlas tools like `bash` and `edit` to enable Deno commands like `deno test` and `deno fmt` in CI. - Atlas integrates with `deno.json` to understand Deno project structure and tasks. - Resume or fork Atlas sessions with `--continue` or `--fork` for iterative Deno development. ## 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. ## Steps 1. Prepare your Deno project: Ensure your Deno project includes a `deno.json` or `deno.jsonc` file, defining your import maps and any relevant tasks. 2. Configure Atlas permissions: Pre-approve the necessary Atlas tools (`bash`, `read`, `edit`, `todowrite`) in your Atlas configuration, as headless runs cannot prompt for permissions. 3. Invoke 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`. 4. Set the model explicitly: Specify the model and provider using the GitHub path format, e.g., `atlas run ... --model 'github/provider/model'`. 5. Parse 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. 6. Resume or fork sessions (optional): If needed, use `atlas run --continue` or `atlas run --fork ` to build upon or branch from previous Atlas sessions in your Deno workflow. ## FAQ ### 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. --- Canonical HTML: https://runatlas.sh/resources/stacks/run-atlas-headless-in-ci-in-deno Source of truth: aeo_pages row `/resources/stacks/run-atlas-headless-in-ci-in-deno` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.