Call Me Back Only When You Need Me

Using Claude Code recently, I got stuck on what looked like a simple question:

When the AI finishes, or hits something only I can decide, can it get my attention?

Plenty of tasks do not need me watching. I can hand the work over and go read something, write documentation, even work on something else. The ideal: the AI runs in the background and calls me back only when —

• The task is done.
• An operation needs approval.
• Critical context is missing.
• There are several options and the choice is a product or business judgment.
• The action could have irreversible external effects.

I assumed this was "turn on notifications." It turned out the real question was not whether the AI can notify me, but:

Under what circumstances should the AI interrupt me?

Step 1: make the notification actually work

Claude Code offers several local notification methods. Some depend on a particular terminal, some use dedicated control sequences, and one is the most universal: sending a bell signal to the terminal.

The signal itself is not complicated. Claude Code emits it when a task completes, when it is waiting on permission, or when it needs input. The terminal then decides how to express it — play a sound, flash the taskbar, raise a desktop notification, or do nothing at all.

Which explains why "notifications are already on" does not guarantee you see anything. A notification is a chain:

AI enters a waiting state
  → emits a notification event
  → terminal receives the signal
  → OS surfaces sound / taskbar / popup
  → the human notices and comes back

Any layer misconfigured and the result looks identical to "the AI never told me."

On my machine the behavior was: nothing at all. I first assumed Claude Code had no such feature and went looking elsewhere. A friend recommended Zed; before switching I asked ChatGPT how to fit Zed into my workflow and stated my requirement, and during that conversation it mentioned Claude Code had a setting for exactly this. I tested it, found it real, and configured it — notification sound on.

In Claude Code: run `/config`, find "Local Notifications", select "Terminal Bell"

The technical problem was solved. A new one arrived immediately.

Step 2: the notification worked, and became annoying

While executing, Claude Code frequently runs commands, searches code, checks file status, or chains several terminal operations together. Permission confirmation is reasonable from a safety standpoint: an AI should not hold unlimited execution rights by default, especially for deleting or overwriting files, installing dependencies, changing system configuration, committing or pushing, deploying, calling the network, or reading secrets.

The problem is that the permission system does not always align with human intent.

Sometimes it only wants to search a few files, but stitches several read-only commands into one long shell line. To me that is an ordinary repository check; to the permission system it is an unauthorized Bash operation. The workflow becomes:

hand the AI a task
  → leave the window
  → get a notification
  → come back and click allow
  → leave again
  → get another notification a few minutes later

It notified me, and my attention got sliced finer than before.

That is when I realized: what I want is not notifications, it is necessary notifications — more precisely, clearer permission boundaries and better task design. If the AI calls a human back for every low-risk step, even a perfect notification system is just efficiently manufacturing interruptions.

Step 3: lower the density instead of switching it off

The obvious move is to turn notifications off — which returns you to "the AI stopped and I did not know." The other extreme is bypassing permissions entirely, so the AI runs free: fewer confirmations, and the most important safety boundary is gone too.

The right answer is not choosing between all notifications and none. It is layering the operations.

Layer 1: allowed to run silently

Low risk, high frequency — let the AI finish them:

• Reading project files, searching code and documentation.
• Checking git status and diffs.
• Running checks, lint, tests, and builds already confirmed safe.
• Reversible edits inside the project directory.

These should not require repeated confirmation. What works better:

• Prefer the built-in read, search, and file tools over stitching complex shell for a simple query.
• Create project-level permission rules for verified common commands.
• Loosen gradually in trusted projects rather than opening everything at once.

Layer 2: tell me, without manufacturing urgency

Needs a human, but is not urgent:

• A round of work is done.
• Several implementation options are on the table.
• A requirement or business judgment is missing.
• It is unsure about the next direction.

These suit visual signals — taskbar flash, window flash, a status indicator — rather than a bell each time. Sound carries inherent urgency and forces an immediate reallocation of attention; most AI tasks are not that urgent.

Where I landed: keep the taskbar/window state indicator, mute or lower the high-frequency sound. I still know it is waiting for me, without being yanked back by every ordinary completion.

Layer 3: interrupt me loudly

What deserves a hard interrupt is anything potentially significant or irreversible:

• Deleting many files, overwriting important data.
• Pushing to a remote, publishing a site or app, changing production.
• Sending email or messages, paid operations, using sensitive credentials, affecting external users.

Here, human confirmation is not friction. It is a necessary control point in the system.

Step 4: from permission config to task design

Reducing interruptions cannot rest on an allowlist alone. How the AI understands the task raises or lowers the confirmation count directly.

Instead of "check this project," write:

First inspect the repository state and relevant files read-only. Prefer file reads, search, and read-only git commands; do not modify files, install dependencies, access the network, or deploy. Report back when the analysis is done.

That states in advance what is allowed, what is forbidden, what needs no asking, and where to stop. The permission system holds the final safety boundary; the task description removes pointless collisions. You need both.

What I want is not self-driving

Discussions of AI agents love the word "fully autonomous": plan, execute, test, fix, commit, deploy. In real work I do not necessarily want an uncontrolled agent. This is the same trade-off I made building this site: not handing everything to the model, but writing the boundaries first and then letting it work continuously. Building a site with an AI agent covers AGENTS.md, the content lock, and the publishing gates; this post covers the other half — how it should call a human back when it stops.

What I actually need is low-friction collaboration:

human defines goal and boundaries
  → AI works continuously on low-risk items
  → pauses only at decision points
  → human judges
  → AI continues

Good collaboration is not an AI that never asks. It is one that does not ask constantly about trivia, and does not act alone where it is genuinely dangerous.

Notifications are the interface of human–AI collaboration

This started as a notification bug and exposed a more general problem: when an AI can work continuously for tens of minutes or hours, how does a human re-enter the process?

Notifications are how an agent hands control back.

• No notification at all → you miss the moment to intervene.
• Too frequent → constant interruption.
• Every alert with the same sound and priority → you cannot tell what actually matters.

A reasonably mature agent workflow needs at least these distinctions:

State	Suggested handling
AI executing normally	Stay quiet
Ordinary task complete	Visual signal
Needs additional information	Visual signal
Needs a product or business judgment	Explicit recall
Irreversible or external operation	Hard confirmation
Known low-risk repeated operation	Auto-allow

More notifications is not safer, and fewer is not more efficient. An effective notification brings a person back only when their judgment is irreplaceable.

Principles I am keeping

• Allow continuous low-risk work by default.
• Permissions are not better when broader; build them up gradually.
• Reduce meaningless permission requests before you reach for the mute switch.
• Use visual signals for ordinary tasks; do not let every event ring.
• Deletion, publishing, pushing, and external actions keep a human control point.
• Stating the allowed scope in the instruction measurably reduces back-and-forth.
• Judge an agent not by whether it can run fully autonomously, but by whether it calls you back at the right moments.

What I was really trying to solve was never "how do I make Claude Code play a sound." It was:

How do I let an AI work quietly most of the time, and pull me back precisely when it actually needs me?