Running commands

    The terminal side of Atlarix: builds, tests, scripts, git, dev servers, and long jobs that run in the background.

    What it is for

    One tool covers terminal work: builds, tests, scripts, package managers, git, deployment, reading logs — anything you would run in a shell.

    It runs in your project folder and uses your machine's real shell, so your own syntax and path conventions apply.

    File work does NOT go through the terminal. Reading, writing, searching, and finding files use dedicated tools instead, which are cheaper and reviewable — see the codebase guide.

    Long-running work moves to the background

    A command still running after about 15 seconds automatically moves to the background, and you can start one in the background explicitly.

    Either way the agent keeps working and the result is delivered when the command finishes. There is no polling — you are told when a job goes quiet, and told if one is genuinely stuck.

    Live output streams into the Terminal panel as it runs.

    Waiting on a job without babysitting it

    A quiet job may not be stuck — a build can be silent for minutes. Rather than cancelling it, the agent has three ways to bound the wait:

    • a wake marker, to be woken the instant matching text appears in the output
    • a timeout, to cap how long it may run
    • an "expected to be quiet" flag for dev servers and file watchers, so silence is not reported

    For external state like a CI run, the better pattern is a command that BLOCKS until done (gh run watch) rather than checking repeatedly.

    Dev servers and your app

    Start your dev server from chat and Atlarix picks up the printed localhost URL. Open it as a browser tab and the agent can drive your app — click, fill, and read runtime errors.

    This works in Explore too: running and previewing your app is allowed in read-only modes, because it does not modify your source.

    When a command fails

    You get the exit code and the output, plus a specific next step for common failures — a missing binary, a permission error, a wrong directory.

    A failed command also blocks the turn from being reported as finished, so a task cannot be marked done on top of a red check.

    Your own terminal

    The Terminal tab is a real interactive shell that remembers its output across restarts. You can also give the agent a named terminal so a dev server and a test run stream into separate tabs.

    Terminals you drive yourself are never sandboxed. For how the sandbox applies to agent commands, see Approvals and the command sandbox.