Settings is a rail of pages, each one long page you scroll. This reference covers the Configuration page — every knob, in the sections the app itself shows them in.

The other Settings pages are documented where their subject is: Mail rules (the deterministic layer), Activity log (shown in Developer mode), and Updates (updating). Who you are, your documents and your memory are on a page of their own, About you, behind your initials in the top right corner. Playbooks are on the Reports page. What you work on, the list setup grouped your mail into, is on About you too, under You: rename one, tick Personal, or untick one to leave it out. Each change saves as you make it.

How to read this#

Each setting shows what it does, and its shipped default. A few notes that apply throughout:

• Blank is meaningful. For a brain or model setting, blank means "decide from what is connected" rather than "off" — the specific fallback is given per knob.
• A switch that is off is off for everything, not just the surface you are looking at.
• Four AI slots — the AI that sorts your mail, the default coding CLI, the assistant and the general agent, plus the judge that decides where a report run goes — are set on the cards at the top of the Configuration page rather than as plain rows. They appear below with their fallback rows, which is what you see if those cards cannot load.
• Developer mode decides whether coding agents exist at all. Off (the default), the Coding agent group is not shown and every job goes to a general agent - see Developer mode.

How mail is sorted#

Sort new mail with AI#

intent_classify_enabled · type: switch · default: on

Classify every new message: a task to DO, a question to ANSWER, or FYI to file.

The heart of the funnel. Every inbound message is read (by the AI picked for sorting at the top of this section, guided by SOUL.md) and classified: task = something must be done, so an agent can be dispatched; reply_only = answering IS the work, so a reply is drafted for your approval; fyi = informational, filed with no task and no draft.

Off: every message becomes a task, which turns newsletters into work items. Leave this on unless you are debugging triage itself.

AI that sorts your mail#

triage_ai · type: brain · default: blank · set on a card at the top of the page

Which AI reads and classifies inbound messages.

TWO BRAINS: a small, fast cloud model (Anthropic / OpenAI / Azure OpenAI) classifies each message in under a second for a fraction of a cent, while your CLI agent — the expensive, capable one — is saved for actually working tasks.

ONE BRAIN, TWO GEARS also works well: pick a CLI agent here and set its 'light model' (Docs → Profiles → Manage profiles → Edit) — triage, drafts, summaries and the digest then run on the cheap fast tier (haiku, gemini-flash…) while coding sessions keep the agent's main model. No second API key, one bill.

Left blank, it is your default brain on its light gear (haiku for Claude) - never whichever connector was added first. Obvious automated noise is filtered by cheap heuristics before any AI is called either way.

Backup AI connections#

triage_backup_ai · type: brains · default: blank

Ordered alternatives for triage, reply drafts, summaries, reports, and assistant chat when the chosen AI is unavailable.

Pick more than one. Taskuary tries them in the order shown when the primary brain hits a session or usage limit, is signed out, has no key, or otherwise refuses the call. A fallback uses its own default model; a model name chosen for Claude is never handed to Codex.

This starts blank because crossing from a cloud API to a local CLI can change cost and privacy. Once you name backups, the same chain protects every short/background AI job as well as the non-coding assistant.

Use playbooks#

playbooks_enabled · type: switch · default: on

Triage matches new mail to your playbooks, and agents may propose new ones.

On: triage is shown every playbook that is switched on, a message that is an instance of one becomes a task worked from it, and a finished job that will recur is proposed as a new playbook for your approval. Off: no playbook is matched or proposed; the playbooks themselves stay on Reports → Playbooks, and a single one can be switched off there instead.

AI for the Assistant#

concierge_ai · type: brain · set on a card at the top of the page

Which AI speaks on the Assistant tab and in your phone chat, and walks you through the pipe - the Assistant's own brain. auto = your default coding agent, on its faster, lighter model.

THREE DEFAULTS, side by side in How mail is sorted: the triage brain, the default coding CLI, and this one.

A CLI agent here can ACT - read a task or message, rerun a report, run a data tool - because it has a shell; it runs in its own scratch folder on a light model (Claude: haiku, Codex: low effort, Gemini: flash, or the agent's own 'light model' from Docs → Profiles) and picks its conversation back up turn to turn, so only the first turn pays the start-up. An API connector answers faster but can only talk. Sending, approving and pushing are your buttons whichever speaks.

Model for the Assistant#

concierge_model · type: text · set on a card at the top of the page

A different model for the Assistant tab, if you want one (e.g. sonnet, or gpt-5.4-mini). Blank = the faster, lighter default. Add @low, @medium or @high to set how hard it thinks, e.g. claude-sonnet-5@medium; a Claude model with nothing added thinks at low.

For a CLI this is its --model, and model@effort sets its reasoning effort (Claude --effort, Codex model_reasoning_effort); for an API connector, its model or deployment name. Changing it starts a fresh CLI conversation.

AI for general agents#

assistant_ai · type: brain · default: blank · set on a card at the top of the page

Which AI works every general task - research, planning, writing, a job with no repository - and answers the floating bubble. Your phone talks to the Assistant, not this.

Normally set on the General agent card at the top of this tab; this row is the fallback if that panel cannot load. A CLI here can run tools, drive a browser and post to the wall; an API connector has no shell, so it can only read and write - quicker, and enough for chat. Blank = the first active API connector, else the default agent.

Where reports go#

judge_ai · type: brain · set on a card at the top of the page

Which AI decides whether a finished report waits under Reports, reaches you right away, or goes out.

Normally set on the 'Where reports go' card at the top of this section; this row is the fallback if that panel cannot load. Four yes/nos about a result somebody else wrote, judged against the sentences on the report's own card - it never has to write anything, so a decision model belongs here and a chat model is wasted on it. Blank = the brain that writes each report judges its own run.

AI that drafts replies#

draft_ai · type: brain · default: blank · set on a card at the top of the page

Which AI writes the replies and messages you approve, and their subject lines. Blank = the triage brain, as before.

Normally set on the Drafting card at the top of this section; this row is the fallback if that panel cannot load. Every reply used to be written by the triage brain, which wants your cheapest, quickest model; a reply in your voice is worth a better one. Nothing is sent without your press, whichever writes it.

Drafting model#

draft_model · type: text · default: blank · set on a card at the top of the page

A different model for drafting, if you want one. Blank = the drafting brain's own light model, as before.

For an API connector this is its model or deployment name; for a CLI, its --model, and model@effort sets how hard it thinks.

Which AI does each job#

ai_route_mode · type: select · default: auto · set on a card at the top of the page

Auto, the default: triage judges each task quick, normal or hard, and quick work runs on a smaller model, hard work on a stronger one. Fixed runs every job exactly as its card says.

Options: fixed, auto

Normally set on the line above the AI cards; this row is the fallback if that panel cannot load. In Auto each card is its job's normal model, and the rules under it say when the quick or the strong model runs instead - each shown as a sentence with its own switch. An AI with only one model thinks less for quick work and harder for hard work instead, where it takes an effort setting (Claude Code, Codex, and the Anthropic, OpenAI and Azure OpenAI API cards); any other AI stays on its one model. An explicit pick - yours, a report's, a workflow's - always wins, and nothing is sent without your press either way.

Strong-model uses a day, at most#

ai_route_strong_cap · type: text · default: blank · set on a card at the top of the page

At most this many calls a day on a strong model, in Auto. Blank = no cap.

Normally set on the line under the rules; this row is the fallback if that panel cannot load. Past the cap, work that would step up runs on the standard model and its route says why, and an unsure answer is not asked again. The count is of today's strong routes in the route log, so you can see what used it.

General agent model#

assistant_model · type: text · default: blank · set on a card at the top of the page

Override the model for the brain above. Blank = the provider's own default.

For an API connector this is its model or deployment name; for a CLI it is the profile's light model. Changing it starts a fresh CLI conversation.

Default AI for agents#

default_brain · type: text · default: blank · set on a card at the top of the page

Which AI program runs an agent's work when its role does not name one. A role (coding, researcher, analyst) decides the instructions an agent starts with; this decides which program follows them. Blank = each profile's own program.

Set from the cards above in normal use — this is the raw value they write. Naming a brain here is what stops a role name being read as a CLI name, which is how TQ-0588's coding work was once routed to Copilot.

A role and a brain are different questions and one name cannot answer both.

Fallback AI programs#

backup_brains · type: text · default: *

Tried in order when the first one has used up its allowance, is signed out, or will not start. * = every other one you have set up, in the order they are listed.

Failover is for AVAILABILITY failures only — session/usage/rate limits, quota, expired login, a missing executable — never for an agent that simply erred. The task, its messages, attachments, repository and seed prompt all travel to the replacement, which starts a fresh conversation with its own model.

A different AI for one role#

profile_brains · type: text · default: blank

For a role that should run on a different AI from the default above. Written as JSON, e.g. {"researcher": "codex"}. Blank (the default) means every role uses the default.

The escape hatch for 'the analyst should run on codex but everything else on claude'. An unknown role name is ignored rather than guessed at. Edited here because it is rare enough not to earn a picker.

Default coding CLI#

default_agent · type: agent · default: blank

The CLI agent that works tasks when nothing names one.

Start session, Send to coding agent and auto-dispatch all use this agent unless you pick another in the moment; every agent picker lists it first. The roster itself lives under Docs → Profiles → Manage profiles, where the default row wears the star.

GitHub-specific permissions (may agents open issues? push?) are on the GitHub connector card, because they are decisions about how your team uses GitHub, not about Taskuary.

Replies#

Email signature#

email_signature · type: signature · default: blank

The block that goes under every email Taskuary writes for you - exactly this, once. Read it from your sent mail, then fix anything.

Saved here, it is the only signature on an email: the AI is told not to sign, any sign-off it writes anyway is taken off, and this block goes under the text exactly as you see it. Chat messages (Teams, Slack, WhatsApp) never get it.

Read it from my sent mail finds the closing lines most of your sent mail shares - quoted history is cut first. Blank: the sign-off line in STYLE.md, else your name. With several mailboxes, each can have its own - blank uses this one.

Sign every email#

sign_replies · type: switch · default: on

Every email Taskuary prepares ends with the signature above, once - drafts, replies you type, forwards. Chat messages never get it.

On: the signature above (or the one saved for the mailbox it goes from) is in the reply box when it opens, so you see what will go, and it is checked once more as the email leaves - a draft that already ends with it is not signed twice. Off: no signature is added anywhere; what is in the box is what goes.

Draft replies on#

reply_channels · type: channels · default: email,teams,slack,telegram,whatsapp,imessage,discord,github

Which channels get a drafted reply at all. Switch one off and its questions just file.

Options: email, teams, slack, telegram, whatsapp, imessage, discord, github

A question arriving somewhere you never answer from should not open a reply task whose draft has nowhere to go. Turn a channel off and messages from it still come in and can still become real tasks — they simply never get a draft, and the funnel says so in the row's reason ('replies are off for slack').

One answer for the whole app: triage uses it to decide whether a question becomes a reply task, the agent wrap-up uses it to decide whether to draft at all, and the approval buttons on the task use it to decide whether Approve can actually send. They cannot disagree.

Two rules are not yours to change here: GitHub also needs 'Reply to issue/PR authors' on its own card (a reply there is a PUBLIC comment), and the read-only trackers — Jira, Linear, Sentry, PagerDuty and friends — can never carry a reply because Taskuary only reads them.

Check your calendar when a reply is about time#

calendar_enabled · type: switch · default: on

"Tuesday at 1 works for me" is only drafted if Tuesday at 1 is free. Reads the Outlook card's calendars (needs the Calendars.Read application permission) and a Google calendar if its OAuth fields are on the Gmail card.

When the thread mentions a day, a time, a meeting or availability, the responder fetches your busy slots for the next 14 days and is told: never offer a busy time; if the asked time is busy, say so and offer the nearest free one; if the calendar could not be read, say you will confirm. The task gets a note that the calendar was checked.

Agents can read the same thing: POST /api/tools/run with type "calendar".

Sharing#

Share links on your network#

share_links_lan · type: switch · default: off

Share on a result can make a read-only link to it that people on your network open in their browser.

Off (the default): no shared link exists and nothing listens for one. On: a second, separate server starts on the Share port below and serves ONE kind of page - a link's frozen copy of one result - to your network. Taskuary itself, and everything behind it, stays on this computer only.

Share -> Shared link takes a frozen copy of that one result and gives it an unguessable address on that port, copied for you to paste. Whoever has the link sees that copy and nothing else of Taskuary - no other result, no task, no setting - and the copy does not change when the result does.

A link expires after 7 days, and Revoke below ends it at once. Turning this off closes the port and every link while it is off. Anyone on your network who is given a link can open it, so share links to results you would email to the same people.

The first time the port opens, Windows may ask whether to let Taskuary through its firewall - allow it on private networks for others to reach the link.

Share port#

share_port · type: number · default: 7797

The port share links are served on, separate from Taskuary's own. Blank = 7797.

Only the shared pages are served on this port; Taskuary's own port stays on this computer. Change it if another program already uses 7797 - links made before the change stop working, because they name the old port.

Assistant#

Semantic search#

kb_semantic · type: switch · default: off

Find documents by meaning, not only by their words: "time off" finds the leave policy.

Off (the default): the knowledge base is searched by keywords, exactly as before, and nothing extra is installed or run.

On: each passage is turned into a vector by a small embedding model as it is indexed, and a search merges the nearest passages with the keyword hits. Needs an embedding model served at the address below (Ollama by default: ollama pull nomic-embed-text). Passages indexed before you switched this on are embedded by the next Reindex. If the model is unreachable, search quietly falls back to keywords.

The text of your documents goes to that address to be embedded. The default is this machine; point it at a remote server only if you are content for the documents to go there. pip install taskuary[semantic] (numpy) makes the scan faster on a large library.

Embedding server#

kb_embed_url · type: text · default: http://127.0.0.1:11434

Address of a server that answers /v1/embeddings (Ollama, LM Studio, llama.cpp, vLLM).

Default http://127.0.0.1:11434, Ollama on this machine. Any server speaking the OpenAI embeddings surface works.

Embedding model#

kb_embed_model · type: text · default: nomic-embed-text

The model that turns passages into vectors (default nomic-embed-text).

Changing it re-embeds the library on the next Reindex; passages embedded with the old model are ignored meanwhile, so results fall back to keywords until then.

Least similarity (0-1)#

kb_semantic_min · type: number · default: 0.5

How close a passage must be in meaning to count as a hit.

A nearest-neighbour search always has a nearest neighbour, even when nothing is related, so passages below this cosine similarity are dropped. Raise it if unrelated passages turn up; lower it if related ones are missed. Scales differ between models, and the default 0.5 is a starting point, not a measurement for yours.

Fast mode#

concierge_fast · type: select · default: auto

Runs the Assistant's CLI on its provider's fast tier: Codex's fast service tier, Claude Code's fast mode. By default on for Codex and off for Claude.

Options: auto, on, off

Claude bills fast mode as extra usage, outside your subscription, and runs it only when extra usage is turned on in your Claude account; Codex spends your plan's credits faster. Coding and general agents are not changed.

How far back your list reaches (hours)#

funnel_hours · type: number · default: 12

How far back ordinary mail, reports and fyi enter the pipe the assistant walks you through. Drafts waiting for your yes and agents waiting on you always enter.

A first launch must not surface a year of never-triaged mail. Twelve hours is a working day; set it to 48 after a long weekend.

Most items on your list at once#

funnel_max · type: number · default: 25

How many items the pipe shows at once. The rest wait their turn and slide in as you clear it.

Order is kept: an agent waiting on you or a draft for your yes is never the one held back.

A meeting stays on the rail after it starts (minutes)#

meeting_grace_minutes · type: number · default: 5

How long a meeting that has started stays on the work rail. 5 by default.

Hide auto-replies and answered threads#

rail_hide_noise · type: switch

Keeps withdrawn messages, out-of-office auto-replies and threads where yours is the last word off the work rail. On by default.

FYI read together#

fyi_batch · type: number · default: 4

How many fyi the assistant puts in front of you at once. 1 to 10. Until you set it, it follows the screen: six on a large one, four on a laptop or a phone.

An fyi needs no action, so they come in a batch rather than one at a time. Left alone, the batch is sized to the screen that asks - six where they fit without scrolling, four on a screen under 800 pixels tall or a phone. A number you set here is used on every screen. At 1 they arrive singly, which is the slow read-everything walk; at 10 you clear the noise in one card. Anything outside 1-10 is clamped - a 0 would take the fyi lane out of the walk entirely.

Keep past chats (days)#

chat_keep_days · type: number · default: 15

Archived assistant chats older than this are removed once a day. Fifteen by default.

Only the chat transcript goes. What a chat said about a task stays on the task, and memories, rules and correction evidence are never touched.

Assistant on your phone#

Chat with the assistant in WhatsApp or Telegram#

phone_assistant · type: switch · default: off · set on a card at the top of the page

The default for a channel that has never been asked. Each channel above answers for itself once you set it.

Name the Assistant chat on the WhatsApp or Telegram card under Connections first. Taskuary then listens only to messages you send in that exact private chat. Other people, other chats and groups cannot command it. This is separate from the Notifications role, so the Assistant chat is not subscribed to ordinary Taskuary alerts.

It is the SAME walk the Assistant tab runs, on the same conversation and the same pipe: the item on the table stays where it was, a reply you ask for is drafted, and a yes sends it. The choices arrive as a poll on WhatsApp and as buttons on Telegram; typing a choice's number works on both.

This switch is the standing permission. The Assistant tab's own "in WhatsApp" button hands the walk over for a session whether or not it is on; the tab keeps working beside it.

The chat only ever answers you: Taskuary writes to it only while you are talking to it there (your last message within 30 minutes, until you say stop) - never a reminder, a follow-up or a summary on its own, and not an urgent item either unless you turn on "Text me urgent items even when I haven't written".

Because answers can contain private workspace information, use a chat only you can read — WhatsApp's Message yourself, or your own private chat with the Telegram bot. Off (default) leaves your messages ignored as before.

Text me urgent items even when I haven't written#

phone_urgent_unasked · type: switch · default: off

Off (default): the Assistant chat stays quiet until you write to it, however urgent something is. On: urgent items may reach it anyway.

Taskuary writes to your own WhatsApp or Telegram chat only while you are talking to it there. Off (the default), that holds for urgent items too: they are shaded on the desktop and wait there.

On: an urgent item may reach the chat even when you have not written - a move on a task marked urgent, an urgent by-the-way while the walk is handed to the chat, and a report's alert aimed at your own chat. Nothing else changes: reminders, follow-ups, the morning line and summaries still wait until you write. Replies to other people are not affected by this switch.

Which chat the Assistant tab offers#

phone_walk_channel · type: select

The "Walk me through them in ..." button on the Assistant tab: WhatsApp, Telegram, or both.

Options: both, whatsapp, telegram

both (default) = a button for each chat that is connected and has an Assistant chat named. whatsapp or telegram = only that one. A chat is offered only once its card under Connections names an Assistant chat, so choosing Telegram before setting it up shows no button until you do.

A morning line in the chat#

phone_morning_line · type: switch

Once a day, the assistant's chat says what is waiting and offers the two ways in: walk me through my tasks, set up a report.

Off by default: the chat says nothing until you write to it or press Walk me through them. On: the first check after 6:00 sends one line to the Assistant chat on every channel that has one - the count in the pipe and how many are on you, then the two scripts as numbered options, so one reply starts the walk there. Quiet on a day the pipe is empty; never twice in a day.

Even on, it goes only into a conversation you started there in the last 30 minutes: the chat never speaks first.

Advisor#

Lines per post, at most#

assistant_max_lines · type: number · default: 5

The Advisor checks in every 30 minutes and on startup (the 'Advisor' report on the Reports tab — edit its prompt for what it watches for, change the cadence, delete it to turn it off) and posts only when it has something to say. How it SPEAKS is COUNSEL.md in Settings → Docs: edit that to change its voice, how bold it is, what it takes a position on. This caps how much one post says. 5 by default.

One AI call per post, and none when there is nothing new. Every line has a key and a state, so it never says the same thing twice. Talk back under a suggestion to correct it or ask a follow-up; the answer and your correction stay with the idea and inform later checks. 'Follow up' drafts the chase in your voice onto the task — nothing is sent by itself; 'Make it a task' starts the agent. Voice: COUNSEL.md (Settings → Docs); what to watch for: the report's prompt. Without an AI connector the facts still post, in the hub's own words. 'Run now' on the Reports tab's Assistant row posts regardless of the schedule.

Silence before a follow-up#

assistant_followup_hours · type: number · default: 24

Hours after your last reply on a thread — one that asked for or promised something — before 'no answer yet, follow up?' appears. 24 by default.

Only your own last word counts, and only when it asked or promised something ('could you send', 'by Friday', a question mark). A plain thanks that goes unanswered is not a follow-up. The chase itself is drafted only when you click.

Quiet days before a task has 'gone cold'#

assistant_cold_days · type: number · default: 3

Open work with no comment, message or run for this many days gets a line. 3 by default.

A task with a live agent on it is never cold. One with a draft waiting on the task is named as waiting on you.

Days of silence before a thread has slipped#

slipped_default_days · type: number

A thread you wrote on, or a step somebody owes, is 'slipped' - first on your rail, with Chase, Let it go, They answered elsewhere and Remind me - once it has been quiet this many days. For a person the outcome ledger has seen answer three times, their own usual day is used instead. 5 by default.

Someone whose auto-reply says they are away never slips. The day is read from the ledger, never from the mail.

Advise on the item that changed#

advisor_events · type: switch

When an agent stops or asks, a reply arrives, a pull request opens, a task closes, a day is missed or a report lands, the Advisor's model reads the item - looking more up when it needs to - and leaves one line and one verb on that item: the ghost text in the prompt box and the pill where the send arrow sits. On by default.

Never a row and never a change to the rail's order: the line attaches to the item and shows when the walk reaches it. The verb is one the item already carries; the number beside it is read from the outcome ledger. Off, the Advisor still runs on its schedule.

Model the Advisor reads with#

advisor_model · type: select

The Advisor's model decides every button it lights, reading the whole item. Standard by default; light saves money and reads less well.

Options: standard, light

In Auto mode the rules under the AI cards pick the tier instead. The finish check, which reads an agent's finished work, runs on the same model.

Event judgements per hour, at most#

advisor_event_cap · type: number

The Advisor's model reads an item once per change and never more than this many times an hour; past it, the change is noted as dropped and the item simply has no pill. 60 by default.

The Advisor's notes on an item (the clock menu) say when a judgement was dropped for the cap.

What it looks for#

assistant_producers · type: channels · default: followup,promise,prep,cold,idea

followup = your unanswered asks · promise = what you said you would do and have not · prep = meetings in the next two days, with what came before them · cold = tasks gone quiet · idea = the model's own thoughts from the day's mail, guided by the report's prompt.

Options: followup, promise, prep, cold, idea

Switch a kind off and it never appears in a post again; lines already posted keep their actions and conversation. 'idea' is the only one that needs an AI connector — the others are read straight off the hub's own tables and your calendar. With 'idea' off no model is called at all: the facts post in the hub's own words.

Agents#

Auto-start the assistant on general tasks#

general_auto_enabled · type: switch · default: on

Every new general task (research, a question to think through, a job with no keyboard) opens its own assistant session with the ask already put. Off: the task waits for you to open it.

Both worker kinds start by themselves by default; each has its own switch. The same holds apply to both: a first-time sender waits for your click (release it from the task), a coding job whose repository is unclear waits for your choice, and a missing AI provider is said on the task instead of failing quietly. A hold never hides the task - it is still triaged and on the Board.

Agents at once#

auto_sessions · type: number · default: 4

How many unattended agent sessions may run together. The rest queue.

The one number that decides how much work this machine takes on at once. Four is the default because four live CLI sessions in four checkouts is about what a laptop stays responsive under — each one is a real process with a real model behind it.

Past the limit nothing is dropped: a dispatched task joins the queue and starts the moment a session ends, and the Board shows it waiting with the reason. The Board's floor view is drawn to this number, so raising it widens the room instead of crowding it.

Raise it if the machine has headroom and your tasks rarely touch the same files; lower it to one if you would rather watch a single agent at a time. Sessions you start yourself are never blocked by this.

Chat detail for coding work#

chat_detail_coding · type: detail · default: everything

How much of a coding agent's work its task chat shows: Summary, Steps, or Everything - every tool call with its output and diff.

Every task's agent talks in the same chat. This is where a task working in a code checkout starts. Summary shows what the agent said and made, and the cards waiting on you, with its steps behind one line. Steps shows one line a step, folded under each turn. Everything shows every tool call, its command, output and diff a press away.

Each chat can say its own from the corner of its task header (Chat detail); that choice is kept for that task on this computer.

Chat detail for other work#

chat_detail_other · type: detail · default: summary

How much of a general agent's work its task chat shows: Summary, Steps, or Everything.

The same three stops as coding work, for every task that is not working in a code checkout - research, a reply, a report. Summary is where they start: the agent's words and results, and its cards, with its steps behind one line.

Each chat can say its own from the corner of its task header (Chat detail).

Folders agents may look in for code#

code_folders · type: lines · default: blank

One folder a line. A coding agent picks its checkout under these, or one Taskuary already knows.

Taskuary no longer decides which repository a coding task belongs in. When nothing on the task says it - a GitHub item's own repository, the code you set with Change where the code is - the agent starts in the task's own folder with the list of repositories Taskuary knows, and picks one before it touches any code.

It may also look for a checkout itself, and this list is where it may look: a git checkout under one of these folders, or one Taskuary already has a path for. Anything else is refused. A checkout it finds that Taskuary did not know joins the repository map, with a line saying where it was found.

Blank means the usual places for code on this computer that exist: Documents, source/repos, repos, projects, code and src in your home folder. Keep it small - every folder here is one an agent may open.

Coding agent#

Hand answers to the working agent#

answer_to_agent · type: select · default: ask

An agent asks a question mid-task, Taskuary asks the person, and their reply lands back on the same task. This is what happens next. ask = the task offers one click, 'Type this into the agent's session'. auto = it is typed in the moment it arrives, as if you relayed it. off = it just sits on the task.

Options: ask, auto, off

Only a LIVE session is ever typed into. If the agent already exited nothing happens and the answer simply waits on the task, so auto cannot lose anything.

The reason this is a choice rather than always-on: auto puts someone else's words into your agent's session without you reading them first. That is usually what you want on your own team's mail and rarely what you want from a stranger's reply, and Taskuary cannot tell the difference well enough to decide for you.

How finished work lands#

git_flow · type: select · default: pr

A draft pull request, or the commits pushed straight onto the default branch.

Options: pr, direct

pr (default) = a DRAFT pull request from the task's branch; it merges only when you approve its merge on the task (Merge), or when you merge it on GitHub yourself. direct = the commits already in the checkout are pushed straight onto the default branch — no PR, no review ceremony, which is usually what you want on your own repository.

Direct mode is deliberately narrow: it pushes commits that ALREADY EXIST. A dirty checkout is refused rather than committed for you (Taskuary will not write a commit message over work nobody has read), nothing ahead of the remote is simply 'nothing to do', and a rejected push is reported for you to pull and rebase — it never force-pushes.

Either way 'Agents may push / deploy' on the GitHub card is what allows anything to leave the machine at all, and CI watching follows the work to wherever it landed.

Watch CI on the task's pull request#

ci_watch · type: select · default: off

A red build goes back to the agent that wrote the code, with the failing check named.

Options: off, feedback, watch

Once a task has a draft pull request (open it from the task, or let the agent propose one), every sync refreshes its checks.

feedback = a failing build is typed into the live session — 'these checks failed, fix the cause and push again, do not merge' — and recorded on the task; if no session is live the task returns to 'open' so it lands on you. watch = the state is shown on the proof card but nothing is handed back. off (default) = no polling at all.

Each distinct failure reaches the agent ONCE per commit, never on every poll. Taskuary opens drafts; a merge waits for your yes on the task's close-out.

Agents may propose actions#

proposals_enabled · type: switch · default: on

An agent can ASK to open a PR, comment publicly, close an issue or run a tool — each waits for your approval.

High-impact actions come off the auto-approve road entirely. Instead of doing them, the agent writes a typed proposal in its transcript (TASKUARY-PROPOSE {"action": "open_pr", …}); when the session wraps up, each valid one becomes a pending review saying what it wants and why. Approving RUNS it; rejecting does nothing.

Every proposal is re-validated at execution, so approving never grants a permission you have switched off — an open_pr proposal still needs 'Agents may push / deploy', a public comment still needs the GitHub card's reply switch. Malformed or unpermitted proposals are refused and recorded on the task rather than dropped silently.

Tell-the-agent notes land one per stop#

waitroom_drip · type: switch · default: on

On: a queue of prompts drips in - each time the agent stops, the next one is typed in, the rest wait their turn. Off: everything queued goes in as one batch.

The waiting room is a funnel: paste twenty prompts and each becomes its own note, in order. With the drip on, the agent gets one at a time with its full attention - it is told how many wait behind it and that the next comes when it stops again, so it never goes looking. Turn it off to hand over the whole list in one message instead.

Auto-start the coding agent#

coding_auto_enabled · type: switch · default: on

Every new coding task immediately opens a live CLI session in its repository. Off: the task waits on the Board for you to send it.

On: the moment triage says 'this is work' your CLI opens in the task's repository (picked from the SOUL.md repo map) with the full ask seeded: visible on the Board, watchable, interruptible. General work uses the separate assistant auto-start switch. Only plain questions (a reply is drafted instead) and notices (filed) stay out of it. Off: tasks queue as 'needs you' and you start the agent from the task yourself.

A first-time sender from outside your domains never starts an agent by itself - the task lands, you press the button. Requires the CLI installed and signed in on this machine. Nothing ships or sends without your approval either way.

Who may start a worker without you#

trust_own_domain · type: flags · default: 1

An inbound message can open a task AND start the agent on it unattended. These are the four rules that allow it; a sender matching none of them still gets triaged and lands on the Board, and only the unattended start waits for your click.

One control over: your own domains (trust_own_domain), people you have written to (trust_sent_history), people you talk with in chats, and your own feeds (trust_non_email), members of your trackers' projects (trust_trackers)

Three separate switches until 2026-09-16, which meant reading all three to know the answer to one question.

your own domains — every connected mailbox's domain and the owner address.

people you have written to — checked in your own records first, then asked of the mail server once per address and remembered. Earlier INCOMING mail is never evidence: a stranger's second message is still a stranger's. A lookup that fails is not proof either way, so the task says so and waits.

people you talk with in chats — someone you have answered in a one-to-one chat, or vouched for by releasing or trusting their task. A group chat is not a room of people you trust. Taskuary sees your own lines in Teams, WhatsApp and iMessage; in Slack, Telegram, Discord and the chat servers it cannot, so there trust comes only from vouching. Your own feeds (calendar, cloud, billing, the local API) ride on this switch too.

members of your trackers' projects — the tracker's own word that the author is a member; an outsider's item, one with no author, and every alert wait for you until you trust that person, project or alert source.

Turn them all off and nothing ever starts by itself; every task waits on the Board for you. Turning them off does not stop triage, drafting or filing - only the unattended start.

Write the agent a context file#

agent_context_file · type: switch · default: on

Each session gets ~/.taskuary/context/TQ-xxxx.md: this sender's recent mail and what you last wrote them, the topic elsewhere, your calendar, the assistant's read, the learned profile, the whole thread - and the reports of closed tasks on the same sender, subject or repo. The seed says 'read it first'.

The seed prompt is one command line (Windows caps it at 32,767 characters, and when it overflows the ask is what gets cut), so the two-line read rides in the prompt and the rest lives in this file. It is written under Taskuary's own home, never inside a checkout - a stray file in a shared checkout gets staged. Off: the seed carries what it always did and no file is written.

Write Claude Code hooks into your checkouts#

agent_hooks · type: switch · default: on

Taskuary adds four hook entries to .claude/settings.local.json in each repository a session opens, so the Board reads the agent's real tool calls instead of guessing from the screen. Switch it off to leave your checkouts untouched — the Board then falls back to reading the terminal.

The decision here is whether Taskuary may WRITE to your repositories, not whether the Board should be accurate — it should, which is why this ships on.

The file is the project-LOCAL settings Claude itself gitignores, so nothing is committed. Existing hooks are kept and only Taskuary's own entries (marked by the /api/hooks/claude endpoint) are replaced. Removing them by hand is safe; they are rewritten the next time a session opens.

CLAUDE CODE ONLY. The hook format is Claude's, so on codex, copilot, qwen, devin or any other CLI this switch does nothing at all — those sessions are read from the terminal whatever it says.

Let a finished agent close its own task#

agent_self_close · type: switch

An agent that says it has finished wraps itself up: the report is written from its transcript and the reply to whoever asked is drafted for your approval. A session you opened yourself is yours to complete.

Done was a button, which meant a task finished at 2am produced no report and the person who asked heard nothing until somebody opened the tab. The agent knows it has finished long before you look, so it says so.

Every session is told about one command in its prompt: taskuary --done with one sentence. That closes the task, files the report from what is on screen, and drafts the reply - which still waits for YOUR approval before it leaves. A session that merely stops talking never closes anything.

One exception, and the task decides it: when you start or continue a session on a task yourself, the task is marked stay:open. There the command is refused - the agent's sentence is filed on the task and you mark it done.

Off: the Done button, exactly as before.

Quick answers and subagents per agent#

auto_sessions_light · type: number · default: 5

Quick answers and an agent's own subagents count as a fraction of an agent: this many make one.

Agents at once is the whole width of the machine, and lighter work shares it. A quick answer is one call to a model, and a subagent is one an agent started for itself - each is real work, but far less than a session, so this many of them count as one agent.

At the defaults (four agents, five here) four sessions fill the room; three sessions leave room for five quick answers at once; with nothing else running, twenty quick answers can run together. A new session or quick answer waits for room, then starts by itself.

An agent's subagents are never stopped - they belong to its session - so they only make new work wait. Raise this if quick answers queue behind agents too often; lower it to count light work more heavily. 1 counts each one as a whole agent.

Agent permissions#

Run CLI agents over ACP#

acp_cli · type: switch · default: on

General agents on Claude Code, Codex, Gemini and the other CLIs run through the Agent Client Protocol: every tool call and permission is a request Taskuary sees and answers. Off: they run on the command line as before.

On (the default): each tool an agent wants to use is asked for first, and Taskuary answers by its own rules - its own tools and anything that only reads or works in the agent's folder are allowed; a tool that sends mail or chat, a push, a publish or a delete outside the folder waits for you, as it does in a pane. What the agent did is shown step by step, the same as before. Claude Code and Codex speak it through a small adapter, started with npx (installed with npm i -g @agentclientprotocol/claude-agent-acp @agentclientprotocol/codex-acp, each start is about 2 seconds quicker); it drives the CLI you already have, with its own login.

If an agent cannot start that way, that run goes on the command line instead and the log says so once. Off: every CLI run goes on the command line. Coding sessions in a terminal are not affected.

General agents can#

general_agent_hands · type: select · default: cli

What a general (non-coding) agent on a CLI may do. Same as the CLI agent = a shell, files and the connections below, each up to its Authority. Only look things up = read files and search the web, change nothing.

Options: cli, look

A general agent used to be read-only by inheritance from the brain that reads incoming mail - not by a decision (2026-10-05). It now runs with your CLI agent's own permissions, in Taskuary's scratch folder, unless you choose 'only look things up'.

What it may change in your other systems is each connection's Authority, in the table below. Every connection starts at full - what your CLI agent could already do with those credentials - and you narrow the ones you want: at read it can look, and any change becomes a proposal you approve on the task; at write it makes the change itself. A SQL query through a read-level connection is rolled back, whatever it contains.

Mail from someone you do not know never starts an agent by itself - general or coding - so these permissions are only used on work you or a trusted sender started.

Private GitHub repositories#

repo_trust_private · type: select · default: ours

Who writes pull requests on a private repository. Your own people get an ordinary agent that starts by itself, no prompts.

Options: ours, outside

Only people you added can write to a private repository, so its pull requests are your own people's work: they batch together and an ordinary coding agent reviews them, started by itself, with no prompts.

Choose "treat as outside" to give them the same protection as a stranger's pull request on a public repository.

Public GitHub repositories - who is yours#

repo_trust_public · type: select · default: writers

On a public repository anyone can open a pull request. People with write access can push anyway, so trusting their pull requests adds nothing; everyone else's are outside.

Options: writers, nobody, anyone

Trust comes from the role GitHub reports for the author - owner, member or collaborator - which only you can grant and nobody can fake. Having had a pull request merged before does NOT count: one small good change would buy trust for the next.

An outside pull request joins the same task as your own people's and runs with the agent's normal permissions. The triage first reads its text and its diff; one it judges dangerous - a prompt injection, or a change that reaches beyond the project - ranks last, batches apart and is reviewed read-only: everything beyond reading is refused, never asked.

Outside pull requests#

outside_prs · type: select · default: review

What an outside contributor's pull request gets. Fix it in the cloud runs the agent and the tests on a machine GitHub throws away, never yours.

Options: review, cloud

With "fix in GitHub's cloud", an outside pull request that ranking warned about, and whose review asks for changes, is fixed in GitHub's cloud instead of here. It runs a workflow in the repository: one job with a read-only token checks out exactly the reviewed head, runs Claude Code there (tests, builds) and hands back a patch; a second job, which never runs their code, pushes it to taskuary/pr-. Taskuary opens the fix's pull request with your token so your CI runs on it, and Merge merges it with the contributor's commits.

The repository needs the workflow (Taskuary adds it when you press Set up) and one secret under the repository's Settings -> Secrets and variables -> Actions. Best is ANTHROPIC_API_KEY: an API key made for this alone, with a spend limit on it; CLAUDE_CODE_OAUTH_TOKEN (run claude setup-token) works too, but it is your subscription. The secret sits beside the stranger's code in that throwaway job, where their tests could read it: it is revocable, and it cannot reach your repository or this machine.

Teammate chats#

teammate_chat_power · type: select · default: safe

A coding agent whose task is bound to a WhatsApp, Telegram, Slack or Teams chat with teammates in it. Safe mode by default: it runs like a stranger's task - the CLI's own reviewer, Taskuary's floor, and a key that opens only that task - and its answers still post to the chat by themselves.

Options: safe, full

A teammate's line goes straight into the agent, and the agent's answer goes straight back to the chat - nobody presses anything in between. In safe mode the agent cannot read your other mail, other tasks or Taskuary's files, so a teammate (or someone using a teammate's account, or text a teammate pasted from elsewhere) cannot ask it to fetch them into the chat. Your own lines in that chat do not lift it.

Full power runs the agent with your CLI's own permissions, skipping its prompts, and the shared key that can read every task, every mail and every comment here: whatever a teammate asks it to look up can be posted back to the chat.

Developer mode#

developer_mode · type: switch · default: off

Coding agents that work in a code repository (needs a coding CLI such as Claude Code or Codex). Off: every job goes to a general agent.

Off (the default on a new install): triage never calls anything coding, and every job you hand over goes to a general agent - research, drafting, reading, the browser - on the AI you connected. Nothing asks you about repositories.

On: work that changes code goes to a coding agent, which runs your coding CLI (Claude Code, Codex and the like, connected under Connections). GitHub is optional: with no repository connected the coding agent works in a scratch folder. Setup offers to connect GitHub once this is on.

A task that is already a coding task keeps its coding agent either way. A home that was already using coding agents before this switch existed was turned on for you when it updated.

Notifications#

Sound when an agent raises its hand#

hand_sound · type: sound · default: chime

A session that stops at its prompt, or asks you a question, plays this - from any tab. Off silences it.

The moment worth a sound: the thing you delegated is now waiting on you. It fires once, on the transition from working to waiting, never while you already have the task open in front of you. Sounds are synthesised in the browser - nothing to download.

The desktop notification below is separate: it is the browser's own, so it reaches you when Taskuary is behind other windows, and the first time it asks for permission.

Desktop notification when an agent raises its hand#

hand_desktop · type: switch · default: on

The browser's notification, so it reaches you when Taskuary is behind other windows. Click it to jump to the task.

Attachments & images#

AI reads attached images#

vision_enabled · type: switch · default: on

Screenshots go to the triage AI — "see below" mail is read, not guessed at.

Half of "see below" mail says nothing in its body: the screenshot IS the request. On: attached images (PNG/JPEG/GIF/WebP, up to 4 per message, 5MB each) ride along into triage when the model has vision, and coding sessions get the local file paths to open themselves.

Off: only text is ever sent to the AI — the setting to use if your model lacks vision or images must never leave the machine. The panel still displays attachments either way.

Charts on reports#

report_images_enabled · type: switch · default: on

Reports hand back a bar chart alongside the spreadsheet.

A report's rows always come back as an .xlsx; with this on they also become an .svg bar chart drawn in the panel — and the summarizing model, which just read every row, picks which column to plot (better than a heuristic grabbing the id column). Off: spreadsheet only.

Sync & startup#

Background sync (minutes)#

poll_minutes · type: number · default: 10

How often the app checks your connections while it is open. 0 turns it off.

The server keeps this clock, so it runs whichever tab you are on and whether or not you are looking at the app - it is also what makes a SCHEDULED REPORT fire on time, since reports are checked on the same pass.

It used to live in the Timeline tab instead: the countdown died the moment you opened Board or Tasks, restarted itself every time you changed a filter, and with the window closed nothing polled at all - so a report set for 8am Monday only ran if somebody happened to be sitting on the Timeline at 8am on Monday.

10 is the default. Lower it if you want mail sooner and do not mind the API calls; 0 turns recurring background polling off. Sync now, startup catch-up, and an action that must refresh chat context can still fetch.

Chat connectors (Teams, Slack, Telegram, WhatsApp, iMessage, Discord) also have a separate recurring fast clock - every 30 seconds unless their card says otherwise. 0 here disables both recurring clocks; manual Sync now, startup catch-up, and action-time refreshes remain available.

Catch-up window (days)#

startup_sync_days · type: number · default: 3

How far back the app reaches when it opens, for what arrived while it was closed.

Taskuary is a window you open, not a service — at 5:30am it is closed, so 'anything since I last polled' misses the weekend. On startup every trigger connection is asked for this many days; the window only ever WIDENS (a source last polled a month ago is not pulled forward), and duplicates are never re-ingested.

The daily DIGEST.md synthesis runs right after it. 0 = plain incremental poll on startup.

Handled mail, at the source#

mark_read_enabled · type: select · default: 0

What Taskuary does to a message in your real mailbox: nothing, mark it read once the funnel took it in, or that and move it to Archive once it is handled here.

Options: 0, 1, archive

Leave it (default): Taskuary is a pure reader — your inbox still shows every message bold, so nothing about your mailbox changes because you connected it. Mark it read: anything the funnel ingests is marked read at the source, so the bold rows left over are exactly the ones the hub never saw.

Move handled mail to Archive: everything 'mark it read' does, and once a mail is HANDLED here — its task closed, or its row put down with Handled — it leaves your Inbox for Archive, so the Inbox holds only what is still owed. Outlook moves it to its own Archive folder (Mail.ReadWrite), Gmail takes the Inbox label off (All Mail), and another IMAP mailbox uses its Archive folder when it has one; with none, the mail stays where it is. Mail you handled before choosing this is left alone, and mail nobody has handled is never moved.

WHERE IT APPLIES: Outlook mail (needs the Mail.ReadWrite consent), Gmail/IMAP mailboxes (the \Seen flag), Slack channels (the read cursor moves to the newest line taken), Teams (Graph marks the whole CHAT read — there is no per-message read state there) and WhatsApp (blue ticks, via the bridge).

WHERE IT CANNOT: Telegram and Discord bots have no read state to set, and the trackers — Jira, Linear, GitHub, Sentry and friends — have nothing to mark. This setting is simply a no-op for them.

Marking always runs AFTER the message is safely stored and is best-effort: a refused permission is logged and never costs you the ingest.

Display#

Timezone#

timezone · type: timezone · default: blank

The zone the app's clock speaks. Blank = this machine's local time.

Timestamps are stored in the server machine's local time. Name that zone here and every displayed time wears its label (2:44 PM EDT) — and a browser opened from another timezone still reads the stamps correctly instead of silently reinterpreting them in its own zone.

Use an IANA name (America/New_York, Europe/London, Asia/Jerusalem). Takes effect on the next page load.

Work rail lookback (days)#

feed_days · type: number · default: 14

How many days back the Work rail reads. Display only — nothing is deleted.

Purely the rail's window. Older messages stay in the database, in task histories, and in search.

Mail rules#

Rules evaluated before any AI touches a message; no model confidence overrides them. Precedence runs ignore → escalate → auto_answer → draft → task_only, and within one action the lowest order number wins.

Kinds: keyword (pipe-separated substrings matched against subject and body), sender (exact addresses), sender_domain, noreply (a built-in matcher for automated addresses), and first_time_sender (fires when the address has never been seen).

Actions: ignore files it with no task, and it stays visible; escalate puts it in front of you and marks the task urgent — this is the only thing that marks one urgent, so name the senders whose mail should jump your queue; auto_answer auto-approves the draft, which is still never sent; draft is the targeted default; task_only files a task and drafts nothing.

Nothing writes into this table by itself. Not for me teaches a verdict in your memory (LEARNED.md), not a rule here, and muting a sender is Skip this sender.

Your memory#

There is one memory: LEARNED.md, read as sentences on About you → Memory. Every fact you tell the Assistant ("remember that…", "I don't care about the legacy export any more") goes in at once as your own line, under the section it is about. A verdict you give — Not for me, Not for the agent, a kind or a road you corrected, an Advisor idea taken up or turned down — goes in when it teaches something about you, as one line saying what kind of work it is and why; a verdict that repeats what is already there adds nothing, and one that sharpens an older line replaces it. A line about one sender, domain or topic ends with (about: …). Triage, report routing, the Advisor, agents and the Assistant each read the sections that help them; edit a line, or press Forget, to change what they read.

Activity log#

Shown in Developer mode. Every consequential thing Taskuary does is one row in an append-only log: a message routed or filed and why, a verdict, a reply sent, an agent session opened or wrapped, a connector saved, a setting changed, a task deleted.

Each row stores a hash of its own contents plus the hash of the row before it, so the rows form a chain. Change any row after the fact — even one character in the database — and its hash no longer matches, and every row after it points at a parent that no longer exists.

Verify recomputes the whole chain from the first row:

The history below it is that log, newest first: when, who, what was done, and to what. It is the answer to "why did this happen" and "who did this" for anything on the rail or the Board.