Wave 1: merge the 78 checked fix PRs into main

.github/workflows/audit.yml

@@ -0,0 +1,47 @@
+# Known security advisories in the packages we ship (ATO-1415).
+#
+# Reads only the lockfile against the npm advisory database, so it needs no install. Dev-only
+# packages (vitest, esbuild, ...) are left out: they never reach users. A high or critical
+# advisory fails the check; fix it with a patch-level bump or an `overrides` entry in
+# package.json, the way PR #1079 did.
+#
+# Kept out of the Test workflow on purpose. The advisory database changes on its own, so a
+# check on every PR would turn unrelated PRs red the day a new advisory lands. On PRs it runs
+# only when the dependency files change; new advisories against main are caught by the push
+# and weekly runs instead.
+
+name: Audit
+
+on:
+  pull_request:
+    branches: [main]
+    paths:
+      - package.json
+      - package-lock.json
+      - .github/workflows/audit.yml
+  push:
+    branches: [main]
+  schedule:
+    - cron: "17 6 * * 1"
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  audit:
+    name: npm audit (production dependencies)
+    runs-on: ubuntu-latest
+    timeout-minutes: 5
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: "25.7"
+          check-latest: true
+
+      - name: Audit the lockfile
+        run: npm audit --package-lock-only --omit=dev --audit-level=high

README.md

@@ -81,6 +81,8 @@ The desktop app is in the same repository as `atomic-agent-desktop` (on Arch `at
 
 Debian, Ubuntu (x86-64, arm64):
 
+> **Not in the apt repository yet.** Until the next release rebuilds the repository, `apt install atomic-agent-desktop` answers "Unable to locate package". For now, download `Atomic-Agent-<version>-amd64.deb` (or `-arm64.deb`) from the [releases page](https://github.com/AtomicBot-ai/atomic-agent/releases) and install it with `sudo apt install ./Atomic-Agent-<version>-amd64.deb`. The dnf and AUR commands below already work.
+
 ```bash
 curl -fsSL https://atomic-agent-packages.fsn1.your-objectstorage.com/atomic-chat.gpg | sudo tee /usr/share/keyrings/atomic-chat.gpg >/dev/null
 echo "deb [signed-by=/usr/share/keyrings/atomic-chat.gpg] https://atomic-agent-packages.fsn1.your-objectstorage.com/deb stable main" \
@@ -154,6 +156,8 @@ If something isn't working:
 
 Building something with Atomic Agent, stuck on setup, or just want to share what you are working on? Grab a slot and talk to the team directly: **[cal.com/atomicagent/demo](https://cal.com/atomicagent/demo)**. No agenda required. Questions, feedback, feature requests, or a plain hello all count. We read every issue and every Discord message too, but sometimes a 15-minute call beats a week of comments.
 
+Found a security problem? Please report it privately, not in a public issue: see [SECURITY.md](SECURITY.md).
+
 ## Benchmarks
 
 On the public **GAIA validation Level 1** split (53 tasks), Atomic Agent and Hermes drove the **same** local `qwen-3.6-35b-a3b` (`llama-server`, UD-Q4_K_XL), with the same step budget and timeout. The only variable is the agent loop.
@@ -353,7 +357,7 @@ Full TUI guide: [TUI.md](docs/user/tui.md).
 "localModels": { "managed": { "parallel": 3 } }
 ```
 
-`workers` (1..8, default 2) is the default fan-out width when the orchestrator does not name one; it is not a ceiling, and the orchestrator can ask for more on a given call. What bounds the width on a local leg is `localModels.managed.parallel`, the llama-server `--parallel` slot count (default `"auto"`, sized from the daemon's context; a number pins it; applied on the next daemon start). On a cloud worker leg the width is capped by `cloudWorkers` (1..32, default 4). The orchestrator model is the provider's `defaultChatModel`; on a local leg the worker model is the one the managed daemon serves. `reviewStallSteps` (default 6, `0` disables) nudges an orchestrator that keeps reading instead of delegating or replying. `turnBudgetUsd` and `turnTimeBudgetMs` (unset or `0`: no cap) cap one fusion turn's spend (the orchestrator's plus the workers', prompt-cache discount included; local tokens count as $0) and its wall-clock time: once either is reached no new delegation or worker starts, running workers are stopped, and the orchestrator is told to tell you plainly what was done and what was not. `escalation: "advisor"` (default `"off"`) lets a stuck worker (the same result three times, six read-only steps, or a first answer cut by its time limit) ask a stronger model for a short hint once; the hint reaches the worker as a mid-turn message and the worker carries on. The escalation model is `escalationProvider`, by default the orchestrator leg, and never the worker leg; each escalation is capped by `escalationMaxUsd` (default $0.25), counts toward the turn's spend cap, and its cost is shown on the worker's row. `escalationReplace: true` additionally re-runs a task that stays stuck after the hint on the escalation model (priced models only). The person can also stop or escalate one running worker by hand (`runtime.fusionWorkers`). `judge: "on"` (default `"off"`, model `judgeProvider`, by default the orchestrator leg) gives every task an acceptance checklist in its brief, built from the contract's checks, provides and declared files plus the task's deliverable; after the work, failed checks, missing provides and missing files are red whatever any model says, and a judge with a fresh context reads the files and rules on the rest. A task closes only on a green list; a red one is re-run once with the findings and reported as failed if still red. The judge's spend counts toward the turn's cap. `autoReplan: N` (default `0`, off; at most 5) makes the planner re-plan by itself: after a fan-out in which tasks did not close (failed, judged red, handed back, out of steps or time), the result lists them with the facts and its next step may only re-delegate them, so you do not have to type "continue"; tasks that depend on a failed one are held for that replan instead of being run against missing inputs. Each task gets N replans per turn; after that the planner is told to report it plainly. `isolation: "worktree"` (default `"off"`) gives every task its own workspace: a detached git worktree of the folder's current state (uncommitted and untracked files included) inside a git repo, a copy of the folder elsewhere. When the task's wave ends its changes are merged back with a three-way merge; files changed by only one task apply cleanly, a file that changed on both sides and cannot be merged is left as it was and the planner gets a merge task for it, a task that wiped a declared input is refused, and a failed task's changes are thrown away.
+`workers` (1..8, default 2) is the default fan-out width when the orchestrator does not name one; it is not a ceiling, and the orchestrator can ask for more on a given call. What bounds the width on a local leg is `localModels.managed.parallel`, the llama-server `--parallel` slot count (default `"auto"`, sized from the daemon's context; a number pins it; applied on the next daemon start). On a cloud worker leg the width is capped by `cloudWorkers` (1..32, default 4). The orchestrator model is the provider's `defaultChatModel`; on a local leg the worker model is the one the managed daemon serves. `reviewStallSteps` (default 6, `0` disables) nudges an orchestrator that keeps reading instead of delegating or replying. `turnBudgetUsd` and `turnTimeBudgetMs` (unset or `0`: no cap) cap one fusion turn's spend (the orchestrator's plus the workers', prompt-cache discount included; local tokens count as $0) and its wall-clock time: once either is reached no new delegation or worker starts, running workers are stopped, and the orchestrator is told to tell you plainly what was done and what was not. `maxRoundsPerTurn` (default 6) and `maxTasksPerTurn` (default 48; `0` turns either off) cap how many delegations and worker tasks one fusion turn may start, counted rather than priced so they mean something on a subscription leg; the fan-out's approval line names the round and the task count. Fusion also stops a fan-out that keeps failing the same way: one worker that fails because the setup cannot work (the worker model does not fit the tool-call protocol, its CLI is not installed or signed in, it is out of credit), or three in a row with the same error, and no new worker starts; the next delegation on that leg in the same turn is refused, and the orchestrator is told to explain the error to you instead of retrying. `escalation: "advisor"` (default `"off"`) lets a stuck worker (the same result three times, six read-only steps, or a first answer cut by its time limit) ask a stronger model for a short hint once; the hint reaches the worker as a mid-turn message and the worker carries on. The escalation model is `escalationProvider`, by default the orchestrator leg, and never the worker leg; each escalation is capped by `escalationMaxUsd` (default $0.25), counts toward the turn's spend cap, and its cost is shown on the worker's row. `escalationReplace: true` additionally re-runs a task that stays stuck after the hint on the escalation model (priced models only). The person can also stop or escalate one running worker by hand (`runtime.fusionWorkers`). `judge: "on"` (default `"off"`, model `judgeProvider`, by default the orchestrator leg) gives every task an acceptance checklist in its brief, built from the contract's checks, provides and declared files plus the task's deliverable; after the work, failed checks, missing provides and missing files are red whatever any model says, and a judge with a fresh context reads the files and rules on the rest. A task closes only on a green list; a red one is re-run once with the findings and reported as failed if still red. The judge's spend counts toward the turn's cap. `autoReplan: N` (default `0`, off; at most 5) makes the planner re-plan by itself: after a fan-out in which tasks did not close (failed, judged red, handed back, out of steps or time), the result lists them with the facts and its next step may only re-delegate them, so you do not have to type "continue"; tasks that depend on a failed one are held for that replan instead of being run against missing inputs. Each task gets N replans per turn; after that the planner is told to report it plainly. `isolation: "worktree"` (default `"off"`) gives every task its own workspace: a detached git worktree of the folder's current state (uncommitted and untracked files included) inside a git repo, a copy of the folder elsewhere. When the task's wave ends its changes are merged back with a three-way merge; files changed by only one task apply cleanly, a file that changed on both sides and cannot be merged is left as it was and the planner gets a merge task for it, a task that wiped a declared input is refused, and a failed task's changes are thrown away.
 
 In the TUI, fusion is the last row of the composer's **Where it runs** switch (`ctrl+r`, or click the backend word): it needs two providers that can answer, one per leg, and says which one is missing otherwise. While it is on, the backend word is an orange chip and the composer and the chat bubbles take the same tint. `/runmode local|cloud|fusion` and `ctrl+g 1/2/3` pick a mode from the keyboard; `/runmode swap` trades the orchestrator and worker legs; `/runmode status` says what the mode resolves to.
 
@@ -681,6 +685,7 @@ Everything Atomic Agent does is inspectable and interruptible:
 - **Failure taxonomy:** transport, grammar, model, tool, and cancellation failures classified across events, traces, metrics, TUI, sidecar, and HTTP.
 - **Allow always:** where a rule can be saved, every place that asks (TUI, CLI, Telegram, Discord, the desktop app) offers a third answer that saves it, for example `Always allow "git status" in this project` (`ctrl+n` in the TUI, `w` in the CLI). Rules live in `<stateDir>/approval-rules.json` (allow, ask, deny) and in a project's `.atomic-agent/approval-rules.json`, where only ask and deny count, so a project cannot grant itself anything. Deny wins over ask, and ask wins over allow. A shell allow rule covers simple commands only (no pipes, `&&` or redirects), while deny and ask rules apply to every command in a chain. Shell rules are saved by program and subcommand. Dangerous commands and secret files never get an allow rule. The desktop app lists saved rules in Settings › Privacy.
 - **Dangerous commands ask every time:** `rm -rf`, `git reset --hard`, force pushes (including `--force-with-lease` and `git push origin +main`), `git clean -fdx`, `git checkout -- .`, `git branch -D`, `find -delete`, `sudo`, `bash -c`, `eval`, `chmod 777` and similar fall in the `shell_dangerous` category. A session grant for the shell never covers them, and approving a Fusion fan-out does not let workers run them; only the top approval level skips the question.
+- **HTTP requests ask per host:** "allow for this session" on an `os.http.request` prompt covers that origin (scheme, host and port) only, so a POST to another host asks again. A redirect that would carry a POST body to another host is not followed; the agent has to make a new request there. Credential headers (`Authorization`, `Cookie`, API keys) are masked in the prompt and are not sent on a redirect to another host. A GET runs without asking by default (`http.approvalMode: "writes"`), and a GET can still carry data out in its URL and headers; set `http.approvalMode` to `"always"` or use `http.hostAllowlist` if that matters to you.
 - **Risk check (opt-in):** with `agent.smartApproval` set to `true` in `config.json` (off by default), a small model rates actions you could grant for the whole session before you are asked. Low-risk actions run; the rest come to you as usual. Categories that cannot be granted, such as `trust_config`, and reads outside the working scope are not rated and always ask. If the check does not answer in 8 seconds, you are asked.
 - **No-progress guard:** repeated identical tool calls draw a warning at 3 repeats and a hard veto at 5; after 3 consecutive vetoes the agent is forced into a graceful reply. Calls are judged on the recent window and on what changed since: re-running the tests after an edit or re-reading a log after a wait is a new question, not a repeat. A deliberate poll (`sleep 60 && tail build.log`, waiting on a background job) is refused only after 20 identical answers.
 - **Per-session FIFO:** every surface enters the same `TurnController`; one session stays ordered while different sessions run concurrently.

SECURITY.md

@@ -0,0 +1,65 @@
+# Security Policy
+
+Atomic Agent runs shell commands, edits files and drives a browser on your machine, so we treat security reports as our top priority. Thank you for helping keep users safe.
+
+## Reporting a vulnerability
+
+Please do not open a public issue, pull request or Discord post for a security problem.
+
+Report it privately in one of two ways:
+
+1. **GitHub private vulnerability reporting (preferred).** Open [Security → Report a vulnerability](https://github.com/AtomicBot-ai/atomic-agent/security/advisories/new) in this repository. Only the maintainers can see the report, and we can work on the fix and the advisory with you there.
+2. **E-mail:** [support@atomicbot.ai](mailto:support@atomicbot.ai). Put `SECURITY` at the start of the subject line.
+
+Please include:
+
+- the version (`atomic-agent --version`, or the desktop release you installed) and your OS;
+- what an attacker can do, and what they need first (a malicious web page, a crafted repository, a hostile MCP server, local access, and so on);
+- steps to reproduce, ideally a minimal proof of concept;
+- any logs or traces, with your own keys removed.
+
+## What happens next
+
+- We confirm we received the report within 3 business days.
+- We send a first assessment (whether we can reproduce it and how severe we think it is) within 10 business days.
+- We keep you updated until it is fixed, and we tell you before anything is published.
+- Once a fix is released, we publish a GitHub security advisory and credit you by name or handle, unless you ask us not to.
+
+Please give us a reasonable time to ship a fix before you disclose the issue publicly. We aim to fix critical issues within 30 days.
+
+## Supported versions
+
+We fix security issues in the latest release of:
+
+- the terminal agent (`v0.x` releases, installed with the install script or a Linux package);
+- the desktop app (`desktop-v0.x` releases).
+
+Both update in place. Please check that a problem still happens on the latest release before you report it.
+
+## Scope
+
+In scope, for example:
+
+- a way to run a command, write or delete a file, send a message or submit a form **without the approval prompt** the action should show;
+- a prompt injection (from a web page, a file, a repository, an e-mail or an MCP tool result) that gets around an approval, a blocked command or a read-scope check;
+- a way to read the agent's own secrets (`<stateDir>/.env`, `config.json`, provider keys) without the prompt that should guard them, or to get them past the masking of secrets in tool output;
+- a way for a project folder to grant itself permissions it should not have;
+- data leaving the machine in a way the [README](README.md#privacy-and-egress) does not describe, including through analytics or crash reports;
+- problems in the installer, the update flow, or the signing and checksums of release files.
+
+Out of scope:
+
+- actions you approved, or that run unasked because you chose a higher approval level, a session grant or an "always allow" rule;
+- at approval level 5 (full trust), or in an overnight run started with `--no-approval`, the agent doing what it is asked;
+- what a skill, a shell command or an MCP server you installed and allowed does on its own;
+- a model giving wrong or harmful answers without crossing a security boundary;
+- issues in third-party services (model providers, MCP servers, websites) that are not caused by Atomic Agent;
+- the atomicagent.io website, unless it affects the agent or its downloads (report those to the same contacts, and we will route them).
+
+## Safe harbor
+
+We will not take legal action against research done in good faith under this policy: test only on your own machine and accounts, do not access other people's data, do not degrade our services, and give us time to fix the issue before you disclose it.
+
+## More
+
+How the agent protects you (approvals, Trash instead of delete, blocked commands, telemetry and signed builds) is described at [atomicagent.io/security](https://atomicagent.io/security) and in the [Safety and Observability](README.md#safety-and-observability) section of the README.