How do I run Atlas in CI for Polars without user interaction?

Use `atlas run` in its default non-interactive mode. It sends a single prompt, streams events to stdout, and exits when the session goes idle, perfect for Polars CI pipelines that need to automate tasks like `LazyFrame` optimization or `pytest` execution.

Can Atlas output machine-readable data for Polars CI automation?

Yes, pass `--format json` to `atlas run`. This streams raw event data to stdout, allowing subsequent pipeline steps to parse and act on Atlas's operations, such as `pytest (assert_frame_equal)` results or `LazyFrame` changes, for automated validation.

How does Atlas handle permissions for tools like `pytest` or `ruff format` in a headless Polars environment?

Pre-approve the necessary tools (`bash`, `read`, `edit`, `todowrite`) through Atlas's permission configuration. Headless runs have no interactive prompt, so all required actions, including running `pytest (assert_frame_equal)` or `ruff format`, must be pre-authorized to prevent session halts.

What's the correct way to specify an AI model for Atlas in a Polars CI script?

Set the model explicitly using the `provider/model` format (e.g., `ollama/codellama`). This ensures the correct model is used for your Polars tasks, especially when working with complex `LazyFrame` optimizations or data transformations, and avoids relying on implicit model selection.

Can Atlas resume a previous session in a Polars CI pipeline if a job fails?

Yes, use `--continue`, `--session`, or `--fork` with `atlas run`. This allows a pipeline step to replay or resume an earlier Atlas session, which is useful for iterating on Polars code changes, debugging `pytest` failures, or continuing complex `LazyFrame` optimizations.

How does Atlas ensure code quality for Polars projects in CI?

Atlas can be configured to run `ruff format` to ensure code style consistency and `pytest (assert_frame_equal)` to validate data transformations and logic within your Polars `LazyFrame` chains. These actions are performed within a permission-gated environment, ensuring automated quality checks.

Does Atlas understand Polars-specific code constructs like `LazyFrame`?

Yes, Atlas is designed to read `LazyFrame` chains, expression contexts, and where `collect()` materializes data. It can help convert `scan_csv` operations into lazy chains for predicate pushdown and print `explain()` on query plans, providing deep Polars-specific insights.

Run Atlas Headless in CI for Polars Projects in 2026

To run an Atlas session non-interactively in a Polars CI pipeline and retrieve machine-readable output, use `atlas run --format json` to stream events, ensuring your `pyproject.toml` pins Polars and that tools like `pytest (assert_frame_equal)` and `ruff format` are configured for headless execution in 2026.

How to run Atlas headless in Polars CI pipelines?

Running Atlas headless in a Polars CI pipeline is straightforward in 2026, leveraging `atlas run`'s default non-interactive mode. This command sends a single prompt, streams all session events to standard output, and then exits automatically once the session goes idle, making it ideal for automated environments.

Atlas is designed for non-interactive execution in CI environments, which is crucial for Polars projects where automated testing and code generation are common. When you invoke `atlas run`, it operates without requiring user input, processing the initial prompt and executing its plan. For Polars developers, this means Atlas can be tasked with optimizing `LazyFrame` chains, converting `scan_csv` operations into predicate-pushdown-ready lazy chains, or even printing `explain()` on query plans to identify performance bottlenecks, all within an automated pipeline. The session's progress and outcomes are streamed, allowing CI systems to monitor and react to Atlas's actions without human intervention. This headless capability ensures that your Polars codebase can benefit from Atlas's AI-driven insights and modifications as part of your regular CI/CD workflow, maintaining high standards for data processing efficiency and correctness.

How to get machine-readable output from Atlas in Polars CI?

To obtain machine-readable output from Atlas during a headless Polars CI run in 2026, simply pass the `--format json` flag to the `atlas run` command. This instructs Atlas to stream raw event data to standard output, rather than human-readable prose, enabling downstream pipeline steps to parse and process the information programmatically.

When automating Atlas in a Polars CI pipeline, receiving structured, machine-readable output is essential for subsequent automated steps. The `--format json` option transforms Atlas's event stream into a parseable JSON format. This allows your CI system to programmatically inspect Atlas's actions, such as the results of running `pytest (assert_frame_equal)` on a modified Polars `LazyFrame`, or the output of `ruff format` after code changes. For instance, a CI job could parse the JSON stream to confirm that Atlas successfully applied a predicate pushdown optimization to a `scan_csv` operation, or that all `pytest` assertions passed after a code refactor. This structured output is critical for building robust, automated workflows around Atlas, ensuring that every change, from minor formatting adjustments to significant `LazyFrame` transformations, can be validated and integrated direct into your Polars project.

How to configure Atlas permissions for headless Polars jobs?

Configuring Atlas permissions is a critical step for any headless Polars job in 2026, as non-interactive runs cannot respond to 'ask' prompts. You must pre-approve all necessary tools, such as `bash`, `read`, `edit`, and `todowrite`, through Atlas's permission configuration to ensure the agent can execute its plan without interruption.

In a headless CI environment, Atlas operates without a user present to grant permissions interactively. Therefore, for Polars projects, it is imperative to pre-configure Atlas's permission settings to `allow` the tools it will need to execute its tasks. This includes core capabilities like `bash` for running shell commands (e.g., `uv install`, `pytest`), `read` for accessing your Polars source files and `pyproject.toml`, `edit` for modifying code (e.g., optimizing `LazyFrame` expressions), and `todowrite` for creating or updating files. Without pre-approval, any attempt by Atlas to use a tool that is set to `ask` will halt the headless session, leading to a failed CI job. By explicitly allowing these tools, you empower Atlas to autonomously perform actions like running `pytest (assert_frame_equal)` to validate data transformations or applying `ruff format` to maintain code style, ensuring a smooth and uninterrupted Polars CI workflow.

How to specify models for Atlas headless Polars runs?

When running Atlas headless for Polars projects in 2026, it is essential to explicitly set the active model and provider. The `atlas run` command requires the model to be specified in the `provider/model` format, ensuring that the correct AI agent is engaged for your specific Polars optimization or code generation tasks.

For consistent and predictable behavior in a headless Polars CI pipeline, you must explicitly define the AI model Atlas should use. The `atlas run` command expects the model to be provided in a clear `provider/model` format, such as `ollama/codellama` or `openai/gpt-4`. This prevents ambiguity and ensures that Atlas leverages the intended model for tasks like analyzing complex `LazyFrame` expressions, suggesting predicate pushdown optimizations for `scan_csv` operations, or generating `pytest (assert_frame_equal)` assertions. Relying on default or implicitly chosen models can lead to inconsistent results across different CI runs or environments. By explicitly setting the model, you gain precise control over the AI capabilities applied to your Polars codebase, ensuring that the agent's context window and specific strengths are aligned with the job at hand, from code indexing with local Ollama embeddings to generating unified diffs for approval.

How to resume or fork Atlas Polars CI sessions?

In 2026, Atlas offers robust capabilities for resuming or forking prior sessions in Polars CI pipelines using `--continue`, `--session`, or `--fork`. This allows a pipeline step to build upon an earlier run, which is particularly useful for iterative development or debugging complex `LazyFrame` optimizations that might span multiple CI stages.

For Polars projects with multi-stage CI pipelines or scenarios requiring iterative refinement, Atlas's session management features are invaluable. The `--continue` flag allows a subsequent `atlas run` command to pick up exactly where a previous session left off, preserving context and progress. This is beneficial when an initial Atlas run might identify a `LazyFrame` optimization but requires further steps, such as running `pytest (assert_frame_equal)` to validate the change, in a separate CI job. Alternatively, `--session` allows you to specify a particular session ID to resume, while `--fork` creates a new session based on an existing one, enabling parallel experimentation or alternative approaches to a Polars problem. These options ensure that even if a CI job fails or needs further iteration, Atlas can efficiently resume its work on your Polars codebase, whether it's refining a `scan_csv` to lazy chain conversion or debugging a `pytest` failure, without losing the context of previous agent interactions or generated code.

Step by step

01Ensure your Polars project's `pyproject.toml` is configured with pinned Polars versions and dependencies are managed using `uv`.
02Define Atlas permissions to `allow` essential tools like `bash`, `read`, `edit`, and `todowrite` within your Atlas configuration for non-interactive execution.
03Invoke `atlas run` with your specific prompt, passing `--format json` for machine-readable output and explicitly setting the model (e.g., `provider/model`).
04Monitor the streamed JSON events from `atlas run` for Atlas's actions, such as running `pytest (assert_frame_equal)` to validate Polars dataframes or applying `ruff format` to maintain code style.
05Parse the JSON output in a subsequent CI step to programmatically validate changes, confirm `LazyFrame` optimizations, or verify successful `pytest` runs.
06Optionally, use `atlas run --continue <session_id>` or `atlas run --fork <session_id>` to resume or build upon a prior Atlas session if a Polars task requires multiple CI steps or iterations.

Frequently asked questions

How do I run Atlas in CI for Polars without user interaction?: Use `atlas run` in its default non-interactive mode. It sends a single prompt, streams events to stdout, and exits when the session goes idle, perfect for Polars CI pipelines that need to automate tasks like `LazyFrame` optimization or `pytest` execution.
Can Atlas output machine-readable data for Polars CI automation?: Yes, pass `--format json` to `atlas run`. This streams raw event data to stdout, allowing subsequent pipeline steps to parse and act on Atlas's operations, such as `pytest (assert_frame_equal)` results or `LazyFrame` changes, for automated validation.
How does Atlas handle permissions for tools like `pytest` or `ruff format` in a headless Polars environment?: Pre-approve the necessary tools (`bash`, `read`, `edit`, `todowrite`) through Atlas's permission configuration. Headless runs have no interactive prompt, so all required actions, including running `pytest (assert_frame_equal)` or `ruff format`, must be pre-authorized to prevent session halts.
What's the correct way to specify an AI model for Atlas in a Polars CI script?: Set the model explicitly using the `provider/model` format (e.g., `ollama/codellama`). This ensures the correct model is used for your Polars tasks, especially when working with complex `LazyFrame` optimizations or data transformations, and avoids relying on implicit model selection.
Can Atlas resume a previous session in a Polars CI pipeline if a job fails?: Yes, use `--continue`, `--session`, or `--fork` with `atlas run`. This allows a pipeline step to replay or resume an earlier Atlas session, which is useful for iterating on Polars code changes, debugging `pytest` failures, or continuing complex `LazyFrame` optimizations.
How does Atlas ensure code quality for Polars projects in CI?: Atlas can be configured to run `ruff format` to ensure code style consistency and `pytest (assert_frame_equal)` to validate data transformations and logic within your Polars `LazyFrame` chains. These actions are performed within a permission-gated environment, ensuring automated quality checks.
Does Atlas understand Polars-specific code constructs like `LazyFrame`?: Yes, Atlas is designed to read `LazyFrame` chains, expression contexts, and where `collect()` materializes data. It can help convert `scan_csv` operations into lazy chains for predicate pushdown and print `explain()` on query plans, providing deep Polars-specific insights.

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 Polars: Terminal-Native AI Coding in 2026

Atlas is a terminal-native AI coding agent for Polars. Build LazyFrame chains, push scan_csv predicates into the reader, and read explain() plans in 2026.

Diagnose a hanging or long-running Polars command with Atlas in 2026

Quickly diagnose hanging Polars scripts or builds with Atlas. Determine if your `uv` or `pytest` commands are genuinely slow or silently blocked on input, and get unstuck efficiently in 2026.

Extract a Shared Helper from Duplicated Polars Code with Atlas in 2026

In 2026, Polars developers use Atlas to find and refactor duplicated logic into shared helpers. Leverage semantic search, pytest (assert_frame_equal), and ruff format for robust code.

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

Streamline GitHub issue and pull request triage for your Polars projects using Atlas. Safely automate responses, code formatting with ruff format, and testing with pytest (assert_frame_equal) for trusted users.

Document a Polars Module with a README in 2026 using Atlas

In 2026, Atlas helps Polars developers create accurate READMEs directly from source code. It leverages `pytest`, `uv`, and `ruff format` to ensure documentation reflects current behavior, not outdated plans.

Run the test suite and triage the failures in Polars with Atlas in 2026

Streamline Polars test triage in 2026 with Atlas. Turn overwhelming `pytest` output into a prioritized list of distinct root causes using `bash`, `grep`, and `todowrite` for efficient debugging.

Audit a Polars Repository with Parallel Subagents in Atlas, 2026

In 2026, Polars developers use Atlas to sweep entire repositories for code issues. Leverage parallel subagents to audit Polars LazyFrame chains and optimize queries without blowing your context window.

Browse this resource hub