---
title: Auto-replies (auto-respond to a session's own output)
---

# Auto-replies (auto-respond to a session's own output)

## What it is

_Auto-replies are the **lightweight** half of Omniscio's two auto-response tools.
They were split into their own sidebar row on 2026-08-14; the **heavy** conditions +
action-chain engine now lives beside them as **[Automation Rules](automations-and-auto-replies.md)**.
Both live in the **Automation** sidebar group. The two share one on/off toggle
(`automationsEnabled`), so turning the feature off hides both rows together._

An **auto-reply** is a simple rule that watches a **session's finished output** —
Claude **or** a non-Claude engine (Codex / Gemini / OpenCode / …) — and, when its
trigger matches, fires **exactly one** action. This is the tool you want when the
goal is "when a session says X, do one thing" — not a multi-step pipeline.

- **Trigger** — one of `keyword`, `project`, `tag`, or `time` (a single condition,
  no AND/OR logic). Keyword / tag matching is a case-insensitive substring of the
  agent's finished turn; text the agent places in a fenced code block, inline code,
  or a `>` blockquote is ignored, so a session that merely **quotes** your trigger
  won't fire the rule.
- **Action** — exactly one of six:
  - **Reply** _(default)_ — inject a message or a Quick Reply snippet so the session keeps going.
  - **Rename the session** — set a new title.
  - **Archive the session** — stop it and archive it.
  - **Start a new session** — spawn a fresh Claude session with a prompt you set. **Billable** — it starts a real session each time it fires.
  - **Add an inbox note** — drop a dismissible note (title + optional body) to yourself.
  - **Organize the session** — set any combination of a new title, a library tag, and an inbox color.
- **Scope** — an optional **Only in project** filter so a rule fires only for
  sessions in one project.

The rules are stored in the `away_mode_rules` SQLite table and driven by the
`AUTO_RUN_*` IPC channels (both names are legacy — the feature was once called
"Away Mode" — and stay byte-stable so existing installs keep working).

## Where to find it

### How to use it

1. Open **Auto-replies** in the left sidebar's **Automation** group (next to
   **Automation Rules** and **Quick Replies**).
2. The panel is a single scrollable list of your auto-reply rules with a **sticky
   filter** at the top (case-insensitive match against the trigger keyword, the
   reply text, and any linked snippet label). Each row collapses to a header
   (trigger + action badge + last-fired / fire count) and expands inline to its editor.
3. Click **+ New auto-reply** in the header bar to create one: pick the condition
   type, enter the match value, then choose **what happens when it matches** from
   the action dropdown. Each action reveals only its own fields. Optionally fill
   **Only in project**. Save.
4. Toggle an individual rule off in its row to silence it — there is no separate
   master switch beyond the shared feature toggle.

### Where the rules also appear

The **same** rules are editable from **Settings → Auto-replies**. Both surfaces hit
the same `away_mode_rules` table via the same `AUTO_RUN_*` IPC, so a change in one
shows up in the other.

## How it behaves

### Loop-safety for the billable actions

The two actions that spend money or re-drive the agent are loop-guarded:

- **Start a new session** — a session an auto-reply itself spawned can never
  trigger another spawn; the same rule can't fire twice for one session within a
  short window; and each rule may spawn at most **50 sessions/day**, past which it
  pauses until local midnight and drops a deduped inbox card.
- **Reply** — a rule only matches the turn that just **finished**, and consecutive
  "no-progress" replies are capped (after which the reply is skipped and the
  session surfaces to you). A substantive turn resets that counter, so a productive
  hands-free run never trips it. Replies are **not** subject to the per-rule daily
  cap.

The other four actions (rename / archive / inbox note / organize) are cheap and
don't re-drive the agent, so they need no cap.

### Auto-replies vs Automation Rules

| | **Auto-replies** | **[Automation Rules](automations-and-auto-replies.md)** |
| --- | --- | --- |
| Watches | a session's finished output (any engine) | incoming channel messages + session/PM events |
| Condition | one simple trigger | AND/OR operators or AI classification |
| Actions | exactly one (of six) | an ordered chain of up to 10 |
| Table | `away_mode_rules` | `automation_rules` |

Most people start with Auto-replies and reach for Automation Rules only when they
need multi-step, condition-rich workflows (forwarding, AI triage, action chains).

## Related

The heavy counterpart to this page is [Automation Rules](automations-and-auto-replies.md), the conditions-and-action-chain engine that shares the same **Automation** sidebar group and the same on/off toggle. The reply text an auto-reply injects is usually one of your saved snippets, covered in [Quick Replies](quick-replies.md), and the triggers that schedule work rather than reacting to output are described in [Cron session jobs](cron-session-jobs.md).