Pushary
Control panel for AI agents on your lock screen
Start new thread

Your agent needs you. Where should it find you?

by
•

I had Claude Code running behind a notes window. It reached a permission prompt and sat there while I kept working. I was on the same Mac the whole time.

That felt worse than missing a finished task. I was not away. The terminal was simply not where my attention was.

A reply on my first thread here changed how I think about this. wrote that agent runs should not own your attention. The reply split the problem into two distances: quiet awareness when you are at the desk, and a real interruption when you are away.

I think that split is right. What I cannot settle is the default.

A. Keep everything inside the terminal.

B. Show quiet state in the menu bar or notch, then expand only when I need to act.

C. Use a normal desktop alert.

D. Send it to my phone even when I am still at the Mac.

E. Use every surface and let me silence the ones I hate.

Which one would you actually leave enabled after a month?

I am especially curious about the last permission you missed. Were you away from the computer, or just working in another window?

Disclosure: I build Pushary. We are working on the Mac side of this problem now. I am asking before we lock the default, because notification settings are easy to add and hard to make people revisit.

306 views

Add a comment

Replies

Best

B makes the most sense to me. Just a small “hey, you need to check this” signal while i'm working in another window would be enough.

 

That’s exactly the distinction. The last thing I want is another notification feed. Just a quiet signal that stays out of the way until the agent actually needs you. One detail I’m still debating: should it remain visible until you act, or briefly pulse and fade?

To make the choice concrete, this is the default I am leaning toward:

At the Mac: a quiet notch signal. No sound, no banner.

If the agent needs a decision: expand in place.

If nobody answers after 60 seconds: send the same question to the phone.

If policy can decide safely: allow or deny silently and write it to the audit trail.

The unresolved part is that 60-second handoff. Too fast and the phone becomes noisy.

Too slow and the agent stays blocked.

Would you want the phone handoff immediately, after a delay, or only when the Mac is locked?

 only when the Mac is locked, for me. an immediate or delayed handoff while I'm still sitting there just means I now get pinged on two devices for the same thing, which is worse than the original problem. lock state is the one signal that actually means "not going to see the notch," everything else is a guess dressed up as a timer.

That is a strong rule because it is observable and predictable. I like it better than a fixed timer while the Mac is active. A sensible default could stay local while unlocked, hand off when the Mac locks, and never duplicate the same request across both surfaces.

For coding agents, I think the severity matters more than the surface. Permission required" should probably interrupt; "task completed" can stay quiet. Not every state change needs equal urgency.

Agreed. The state should choose the interruption level. A completed task can sit quietly in the notch, while a blocked permission request should expand and escalate only if it stays unanswered. The hard part is who assigns severity. Would you trust the agent to label it, or only rules you set yourself?

The menu bar makes the most sense because its persistent without demanding attention. a notification can feel like an interruption before i know whether it matters.

That persistence is the appeal. It can show that something is waiting without deciding for you that it deserves an interruption. I am leaning toward the notch carrying state, then expanding only when an action is required.

I would separate agent needs input from agent finished. the first deserves attention the second usually doesnt.

I think that is the cleanest split. “Needs input” is a blocked state, while “finished” is just durable status. The UI should treat them differently before the user changes a single setting.

C would probably work initially but after a month i can see myself mentally filtering desktop alerts. persistent passive status seems more sustainable.

That is my concern with C too. Banners train you to dismiss them because most are not actionable. A passive state can stay visible without creating urgency, then expand only when the agent cannot continue.

The interesting problem is priority not surface. if five agents need attention i want one useful signal rather than five notifications.

Yes. With several agents, the unit of notification should be the decision queue, not the agent. One signal could show the most important blocking item plus a count of the rest, ordered by impact and expiry.

I feel D is too aggressive for me. if am at my mac my phone shouldnt become another notification channel unless the task is genuinely urgent.

Same instinct. Mac presence should suppress phone delivery by default. The exception should be an explicit critical action, not a generic urgency label from the agent, so the user decides what can cross devices.

For me menu bar by default, desktop alert for blocked actions, phone only for something that will genuinely expire or hold up other work.

That hierarchy feels right: persistent status, local interruption for blocked work, and phone only when delay has a real cost. It gives each surface a clear job instead of mirroring every event everywhere.

I run agents on an ordinary Next app all day, and the permission prompts I used to miss were almost never real decisions. They were the agent asking to run a grep, or a type check, or a test command it had already run forty times that week. Once I allowlisted the read-only stuff in project settings, what was left was rare enough that the surface stopped mattering much.

On your actual question: B, with Gal's lock-state rule. Lock state is observable, a timer is a guess.

But there's a cheaper win before the default. The notch tells me something is waiting and I still have to switch windows to find out what. If it showed the command and let me approve from there, most of the surface question disappears

 This is exactly the distinction we need: remove predictable prompts first, then design the surface for the small set of real decisions. Showing the command with approve and deny controls directly in the notch is the intended interaction, so there is no window switch. Would you also want the relevant output expandable there, or is the command itself enough context?

 The question I'm actually answering at a prompt is usually not "is this command dangerous." It's "is this agent still on track." The command string settles the first one fine. For the second I need the last thing it said before it asked, a line or two of reasoning, because most of my denies aren't "that's unsafe," they're "you've misread the task and this is step four of a wrong plan."

Raw output is the one thing I'd leave out. If it's expandable I will expand it

The exception runs the other way. For something destructive, a delete or a migration or anything touching prod, I want the command and nothing else. Extra context makes me slower on the exact prompt where slow is expensive.

That split is useful. For an off-track decision, the minimum context is not raw output but the agent's last stated intent: current goal, next step, and why this action is needed. For destructive actions, collapse to command, target, and consequence so the decision stays crisp. That suggests two approval layouts selected by policy rather than one expandable card. Would you want the UI to make that mode explicit, or should it happen silently?

12
Next