Go check your terminal. How long has your agent been waiting?
Open the terminal where your agent is running. Do it now, before you read the rest.
Is something sitting there waiting for you? How long has it been there?
I did this an hour ago. Mine had been waiting 15 minutes. I was at my desk the whole time, two windows away.
That is the part I had wrong for a year. I thought this was a "stepped away from the computer" problem. It is not. Most of the waiting happens while I am sitting right there.
So I want to know what everyone else actually does about it.
1. Keep every terminal visible and glance at them
2. Alt tab every few minutes to check
3. Turn the prompts off, skip permissions, hope for the best
4. Wrote your own hook or script to ping you
5. Something smarter, please tell me
The other half of this I am less sure about. @siarheihamanovich said in the last thread that the prompts he missed were almost never real decisions. A grep, a type check, a test command the agent had already run forty times that week. Mine looks the same. Which means half my waiting time is spent on questions nobody needed to ask.
So, two things. How long was yours waiting when you looked, and was the question worth it?
I will post the spread in a couple of weeks.
[I build Pushary, so I am not neutral about any of this. Asking anyway. The last two threads here taught me more than a month of building did.]
Replies
Fair summary of what I said, and I'd go one step further.
I stopped waiting on the grep-and-typecheck prompts by allowlisting them. My project allows `bun run *` for the agent, so typecheck never asks. But your two examples are both `bun run`. The wildcard that killed the boring prompt also waves through the migration. So the allowlist has the same problem as your screen: typecheck and migrate look identical to it.
What actually keeps the migration safe for me is a rule - agent generates migrations and I run them myself
Pushary
@aadilghani Claude Code as the main (and Codex from time to time).
The agent runs drizzle-kit generate, which writes a plain SQL file, and I read that file before anything touches the database. It's usually ten lines, so it takes a minute.
What I'm looking for is the one thing the diff hides: a rename that the tool reads as a drop plus an add. That's data loss dressed up as a schema change. The best migration I ever reviewed was the empty one. We renamed two fields across the whole codebase and the right result from generate was "no schema changes", because the columns stay mapped to their old names.
BTW. And after your thread I closed my own hole. The wildcard stays, but push and migrate are now on a deny list, so the agent physically can't run them. The rule used to be my discipline, now it's config.
Pushary
@siarheihamanovich
"My discipline, now it's config" is the line I am stealing.
We are on Drizzle too, and the rename that generate reads as a drop plus an add is exactly the one that looks fine in a ten line diff. The empty migration as your best review is a great way to put it.
One thing I would check on the deny list. It names commands, and the database does not care which command talks to it. Does it also stop npx drizzle-kit migrate, or only the bun run script?
@aadilghani It catches the bun run scripts and bunx drizzle-kit. npx, bun x with a space, anything wrapped in sh -c all walk straight past it.
Your line is the actual answer though. The database doesn't care which command talks to it, so the fence belongs on the credential. If the shell the agent runs in only holds a connection string for a dev branch, a migration against production isn't blocked, it's just impossible, whatever the command looks like.
Pushary
Mine, so the format is clear.
15 minutes, and I was at my desk for all of it.
I am a 2. Alt tab every few minutes, which means I check most often when the agent is least likely to be asking, and never when I am deep in something.
What it was stuck on: bun run typecheck. It had run that same command several times already that morning.
The part that bothers me more. A few days before that it was bun run db:migrate pointed at production, and that one sat there in exactly the same way. Same silence, same nothing on screen. The command I could have approved blind and the one I actually wanted to read look identical while they wait.
So what is the worst number anyone has, and was it a grep or a migration?
Do you think a sound notification would be enough, or would a desktop/mobile alert be more helpful?
Pushary