# Run Atlas Headless in CI in Erlang with Atlas in 2026 > Run Atlas headless in CI for Erlang projects by invoking `atlas run --format json` to get machine-readable output for automated pipeline processing. To run an Atlas session non-interactively in a CI pipeline and retrieve machine-readable output for your Erlang project, invoke `atlas run` with the `--format json` flag, ensuring your `rebar.config` and `src/*.app.src` files are present. This allows Atlas to stream events directly to stdout, which can then be parsed by subsequent pipeline steps, integrating direct with your `rebar3` and `erlfmt` workflows. ## Key takeaways - Run Atlas headless in Erlang CI using `atlas run` for automated tasks. - Obtain machine-readable output with `atlas run --format json` for Erlang pipeline integration. - Pre-approve Atlas tools like `bash` and `edit` for uninterrupted Erlang headless runs. - Atlas deeply understands Erlang/OTP structures, including `rebar.config` and `gen_server` modules. - Automate Erlang code quality checks by having Atlas run `rebar3 eunit` and `erlfmt`. - Resume or fork Erlang Atlas sessions in CI to build on prior work efficiently. ## How to run Atlas headless in Erlang CI pipelines Running Atlas non-interactively in an Erlang CI pipeline in 2026 is straightforward using the `atlas run` command. This command's default mode is designed for automation, sending a single prompt and exiting once the session becomes idle, making it ideal for a 1-step CI job. For Erlang/OTP projects, `atlas run` integrates directly into CI/CD workflows. When executed in a directory containing a `rebar.config` and `src/*.app.src` file, Atlas automatically indexes your code by AST declarations using tree-sitter, understanding Erlang's specific structures like supervisor callbacks and `gen_server` modules. You provide the initial prompt as an argument, and Atlas processes it, streaming events to stdout. This headless operation ensures your Erlang codebase benefits from Atlas's AI capabilities without requiring manual intervention. ## How to get machine-readable output from Atlas for Erlang CI To enable subsequent pipeline steps to parse Atlas's output for Erlang projects, specify the `--format json` flag with `atlas run`. This ensures that instead of human-readable prose, Atlas streams raw event data as JSON to stdout, providing a structured format for automated processing in 2026. Machine-readable output is crucial for Erlang CI automation. By adding `--format json` to your `atlas run` command, every event from the Atlas session,including tool calls, agent thoughts, and final diffs,is emitted as a JSON object to stdout. This structured output allows other tools in your CI pipeline to programmatically read and react to Atlas's actions. For instance, a script could parse the JSON stream to extract unified diffs or verify that `rebar3 eunit` or `erlfmt` commands were executed. ## How to pre-approve Atlas tools for headless Erlang CI In a headless Atlas run for an Erlang project, there is no interactive user to respond to `ask` prompts. Therefore, it is critical to pre-approve all necessary tools, such as `bash`, `read`, `edit`, and `todowrite`, through the permission configuration. This ensures Atlas can execute its plan without interruption in your 2026 CI environment. Atlas operates with a strong emphasis on safety, with every tool call permission-gated against `allow`, `ask`, and `deny` rules. For headless execution in an Erlang CI pipeline, any tool Atlas might need to use,like `bash` for running `rebar3 eunit` or `erlfmt`, `read` for inspecting Erlang source files, or `edit` for modifying `.erl` files,must be explicitly `allow`-listed. Without pre-approval, Atlas would encounter an `ask` prompt and, lacking a user, would halt the session. This pre-configuration is vital for uninterrupted automation, allowing Atlas to confidently add a `handle_call` clause or create a Common Test suite. ## How to resume or fork Atlas sessions for Erlang in CI Atlas provides robust mechanisms to resume or fork prior sessions, which is invaluable for iterative development or debugging in Erlang CI pipelines. Using `--continue`, `--session`, or `--fork` with `atlas run` allows a pipeline step to build upon an earlier run, saving significant time and context in 2026. Resuming or forking prior sessions is invaluable for iterative Erlang CI. The `--continue` flag allows Atlas to pick up exactly where a prior session left off, preserving the agent's state and context. Alternatively, `--session ` lets you specify a particular session to resume. The `--fork` option is useful for creating a new branch of work from an existing session, allowing for parallel experimentation or different approaches within your Erlang codebase. These capabilities are powerful for large Erlang/OTP systems, where re-indexing from scratch for every CI run would be inefficient. ## Atlas's Deep Understanding of Erlang/OTP Projects Atlas is specifically designed to understand Erlang/OTP systems, going beyond mere syntax to grasp the architectural nuances of projects built with `rebar3`. It maps supervisor callbacks, `gen_server` modules, and release configurations in `relx`, providing a deep contextual awareness for Erlang developers in 2026. Atlas deeply understands Erlang/OTP systems. It builds its code index with local Ollama embeddings and AST declarations using tree-sitter, grasping Erlang's unique characteristics. When run in an application with a `rebar.config` and `src/*.app.src`, Atlas identifies and interacts with core Erlang/OTP components. It can intelligently suggest adding a `handle_call` clause to a `gen_server` module, modify a supervision tree, or propose changes to a `relx` release configuration. This contextual awareness enables accurate modifications respecting Erlang idioms. ## Automated Erlang Code Review and Formatting with Atlas Atlas streamlines automated code review and formatting for Erlang projects by integrating directly with standard tools like `rebar3 eunit` and `erlfmt`. Before committing any changes, Atlas computes a unified diff for every file edit and surfaces it for approval, ensuring code quality and style consistency in 2026. After Atlas drafts a plan in its read-only plan agent and receives approval to switch to a build agent, it can execute Erlang-specific commands. For instance, Atlas can be instructed to run `rebar3 eunit` to validate changes or `rebar3 ct` for Common Test suites, ensuring modifications maintain functionality. Crucially, Atlas can also run `erlfmt` on touched modules, guaranteeing all generated or modified Erlang code adheres to project style. The agent presents a unified diff for all proposed changes, allowing final review even in a headless context (if parsed via `--format json`). ## Steps 1. Ensure Erlang project setup: Verify `rebar.config` and `src/*.app.src` exist for Atlas to understand your Erlang project. 2. Configure Atlas permissions: Pre-approve `bash`, `read`, `edit`, `todowrite` in Atlas config to avoid `ask` prompts in headless Erlang CI. 3. Invoke Atlas headless with prompt: Run `atlas run "Add handle_call to my_gen_server.erl" --format json` for non-interactive Erlang task execution. 4. Set the model explicitly: Use `--model provider/model_name` (e.g., `--model openai/gpt-4o`) in your `atlas run` command. 5. Parse Atlas's JSON output: In CI, parse the JSON stream from stdout to extract diffs or `rebar3 eunit` results for your Erlang project. 6. Review and apply changes (optional): Review proposed Erlang code changes via extracted diffs, or automate staging/commits if tests pass. 7. Resume or fork a session (optional): Use `atlas run --continue` or `--session ` to build on previous Erlang Atlas sessions. ## FAQ ### How do I run `rebar3 eunit` with Atlas in a headless Erlang CI pipeline? Pre-approve `bash` in Atlas config. Prompt Atlas to execute `rebar3 eunit` after changes; it runs behind the permission prompt. ### Can Atlas format Erlang code with `erlfmt` automatically in CI? Yes. Instruct Atlas to run `erlfmt` on touched files. Ensure `bash` is pre-approved, and Atlas will execute it to maintain style. ### How does Atlas understand my Erlang/OTP project structure? Atlas indexes code by AST declarations using tree-sitter, recognizing `rebar.config` and `src/*.app.src`. It maps supervisor callbacks and `gen_server` modules. ### What kind of output does `atlas run --format json` provide for Erlang projects? It streams raw event data to stdout, including agent thoughts, tool calls, and unified diffs. CI tools can parse this machine-readable JSON output. ### How do I prevent Atlas from asking for permissions during a headless Erlang CI run? Pre-approve all necessary tools (e.g., `bash`, `read`, `edit`) in your Atlas permission configuration. This ensures uninterrupted execution in your Erlang project. ### Can Atlas create new Erlang test suites under the `test/` directory? Yes. With `edit` and `todowrite` pre-approved, prompt Atlas to add a Common Test suite; it generates necessary files respecting Erlang conventions. ### How does Atlas handle Erlang code changes and rollbacks in CI? Atlas computes unified diffs for edits and snapshots changes as git patches. Diffs can be parsed from `--format json` output for review or rollback. --- Canonical HTML: https://runatlas.sh/resources/stacks/run-atlas-headless-in-ci-in-erlang Source of truth: aeo_pages row `/resources/stacks/run-atlas-headless-in-ci-in-erlang` (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.