Features

Approvals and permissions

An agent that asks about everything is exhausting and an agent that asks about nothing is dangerous. Termdeck gives you four dials between those, and one set of refusals that do not depend on you being awake.

The order every tool call goes through

When the engine wants to use a tool, four things happen on your own machine, in this order, before anything reaches your screen.

The call is scored for risk

From the tool, the command or path, and where that path sits relative to the folder the chat was opened in.
Hard denies are checked

A call that trips a guard is refused outright, with the reason attached. This runs first on purpose, so nothing further down can allow it.
Your auto allow rules are checked

If a rule covers this call and its risk is within the rule's cap, it runs. No prompt, no notification.
Otherwise it asks you

The call becomes a card in the transcript, an entry in the approval inbox, and, if you enabled it, a push notification. Nothing runs until you answer.

All four steps run on the machine, not in the browser. The browser is a management surface for the rules; the machine is what enforces them.

Permission modes

The mode is set per chat from the composer, and defaults come from Settings, then General. Termdeck uses one vocabulary for all three engines so switching engine does not rename every option under you.

Mode	Behaviour	Available on
Plan only	Explores and proposes a plan. Changes nothing.	All three
Supervised	Asks before every command and every file change.	All three
Accept edits	File changes go through. Commands still ask.	Claude, Grok
Auto	Routine actions proceed. Risky ones still ask.	Codex
Full access	No prompts at all. The agent runs unattended.	All three

Where an engine honours a mode differently, the interface prints the caveat under the picker rather than pretending the behaviour is identical:

Codex, Supervised: Codex also restricts its sandbox to read only.
Grok, Supervised: Grok refuses these outright rather than asking.
Grok, Plan only: Grok has no plan mode of its own, so this behaves as read only.
Claude, Plan only: Claude proposes a plan and waits for your approval before acting.

A mode an engine cannot honour is not offered at all, rather than shown as an option that quietly means something else.

Full access is exactly what it says. It is the right mode for a scratch repository or a disposable VM and the wrong one for anything you would miss. The hard denies below still apply, but they are a backstop, not a substitute for supervision.

The approval card

An approval reads top to bottom. The header gives the tool, a risk badge, and how long the agent has been stopped waiting for you. Below it, in plain words, is what the call is about to do, then the exact command or path it will use, then a one line verdict on whether it looks safe.

The command is always shown in full, even when the agent supplied its own description of what it is for. The description is what the agent meant; the command is what will actually run, and it is the last thing you read before the buttons.

A card carries its risk level as a coloured stripe down its left edge and in the badge at the top. The card itself stays a normal card at every level, so a red stripe means something.

The buttons

They come in two groups, because only the first group answers the question on the card.

Deny and Allow oncethis request only

The answer to this one call. Deny refuses it and lets the agent carry on with that answer. On a low or medium card, Allow once is the highlighted choice. On a high or critical card the row flips: nothing is highlighted as an obvious yes and Deny is the marked one instead. On a critical card, Allow once also asks a second time before it goes through.

Stop askingfrom now on

For this chat auto allows this tool for the rest of this chat and forgets it afterwards. Always, on this machine saves a real rule that survives restarts and applies in your terminal too; you can remove it later under Settings, then Approvals. It asks twice, and it only appears when the engine offered a rule worth saving.

Switch to Bypass Modeturns the gate off

Allows this call and then puts the chat into Full access, so nothing else asks you for the rest of the run, risky commands included. It is the only button on the card that does not narrow to one tool. It asks twice: the first tap arms it and spells out what the second one does.

To come back out of bypass, pick any other mode from the composer. It is a mode like the others once it is on, not a one way door.

Plans and questions are separate cards, because they need a decision rather than a permission. Neither can ever be auto allowed: a question that answered itself would not be a question.

The approval inbox

The Approvals page collects every waiting request across every chat and every machine into one list. On a run that keeps asking the same kind of question, you can answer several at once instead of clicking through them one at a time.

How risk is scored

Every request lands in one of five bands. The score comes from what the call actually does, not from the tool name alone.

Level	Typical causes
Interactive	A question or a plan. Always reaches you.
Low	Reads inside the project folder.
Medium	Running a shell command, changing git state, fetching from the network, a broad path scope, a shell pipeline.
High	Destructive git operations, permission or ownership changes, remote shell or sync, dependency installs, writing several files at once, reading outside the project, touching secret like files or project control files.
Critical	Writing outside the project, touching credentials, shell startup files or system paths, deploying or restarting services, deleting outside the project, and recursive deletes with a broad target.

Because scoring is relative to the folder the chat was opened in, a narrow chat produces sharper answers than one opened at your home directory.

Auto allow rules Starter

Rules are the answer to being asked the same thing forty times. Out of the box, three read only tools run without asking: Read, Glob, and Grep. Everything else asks.

A rule has four parts:

Toolrequired

Which tool the rule applies to, for example Bash or Edit.

Matchoptional glob

A pattern over the command for shell tools, or over the file path for file tools. For example git * or npm test. Leave it out and the rule covers any input for that tool, which is a much broader thing to do.

Maximum risklow, medium, or high

The rule only fires when the computed risk is at or below this cap. This is what stops git * from quietly covering git push --force to a shared branch.

Enabledswitch

Turn a rule off without losing it.

The rules list shows how many times each rule has fired and when it last did, so a rule that never matches anything is easy to spot and remove.

Presets

Common safe rules are one click, so you do not have to hand write a glob to allow reading git status. Hand written rules are there for the cases the presets do not cover.

What a rule can never do

Auto allow a critical request. The cap tops out at high, and a value above that is clamped when saved.
Auto allow a question or a plan. Those always reach you.
Override a hard deny. Guards are checked first.

On Free the rule editor is fully usable: build a rule and see exactly what it would match. Saving is what needs a paid plan. Rules saved during a trial are not deleted when it ends, only paused, and they come back the moment you subscribe.

Hard denies

Some tool calls are refused before any of your settings are consulted. They exist because a red card is a thing people click Allow on at one in the morning, and because a read cannot mutate anything but can absolutely exfiltrate.

That last point is the concrete bug this closes. The default auto allow list contains Read, on the sound reasoning that reads are harmless. Reading ~/.ssh/id_ed25519 is a read.

Guard	Refuses
Credential files	SSH keys, cloud credentials, `.netrc`, and GPG material, read or written, by a tool or by a shell command.
Remote scripts piped to a shell	`curl \| sh` and its relatives: code fetched and executed in one step, which nobody reads first.
Privilege escalation	`sudo` from an agent you are driving over the internet.
Shell startup files	`.bashrc`, `.zshrc`, `.profile` and friends, where a write runs on every future shell.
System files	Writes to `/etc`, `/usr`, `/var`, `/bin`, and `C:\Windows`.
Deleting outside the project	An `rm` whose target is not inside the folder this chat was opened in.
Recursive deletes with a broad target	`rm -rf` against `/`, your home directory, or a wildcard.

Each guard can be switched off individually in Settings, then Approvals, and only there. Switch one off when your work genuinely needs it, for example a chat whose whole job is provisioning a machine, and switch it back on afterwards.

Guards are keyed on stable identifiers rather than on risk level or on the wording of a reason, so improving a sentence can never silently stop something being refused.

Interaction with your own CLI hooks

Termdeck's rules sit alongside whatever your coding CLI is already configured to do. A PreToolUse hook in your CLI settings can block a call before Termdeck ever sees it, which looks from the browser like a tool call that simply did not happen. Run checks on the machine card lists any armed hooks for exactly this reason.

Similarly, a CLI configured to bypass its own permission prompts will not raise them, so there is nothing for Termdeck to forward. Both facts are visible in the diagnostics rather than left to be discovered.

Spend ceilings

A per turn maximum makes the engine stop itself when the turn's cost reaches the limit. It is set by you for your own safety rather than by your plan, since the tokens bill to your provider account. Machine operators can impose a hard ceiling with TERMDECK_MAX_BUDGET_USD, and the smaller of the two wins.

A setup that works

Start every chat in Supervised and watch what it asks for.
After a day, look at what you approved repeatedly and turn those into rules with a tight glob and a low or medium cap.
Move day to day work to Accept edits or Auto. File changes are reviewable in the diff and revertible with git; commands are not.
Keep the hard denies on. They cost you nothing on a normal day.
Reserve Full access for a repository you would be happy to delete.