addAI.dev·Field NotesView as Markdown

By Jay·November 2026

Are We Just Drinking Birds Now?

#TechDeepDive#AITools

In King-Size Homer (The Simpsons, 1995), Homer gets tired of typing yes every time the plant's computer asks him to confirm something. So he leaves a toy drinking bird at his keyboard to press the Y key for him. The bird works until it falls over, and the plant heads for a meltdown.

We spent days being the bird.

Days of pressing approve

We were letting an AI coding agent (Codex, OpenAI's tool) run commands on a second computer on our network. Many commands needed a click to approve. The clicks piled up until we were approving without reading, which is the exact thing an approval is meant to prevent.

Any AI tool that asks allow this? all day puts you in the same seat. We asked whether the agent was using the single connection we had told it to use. It said it was, and added:

What the logs showed

The agent's session log records every command it ran and whether it asked for extra permission. One long working session (about 19 hours of activity across two days):

• 324 commands run in a terminal (102 of them typed into a live session on the other computer), and 59 were flagged as asking for approval. Every one of the 59 was a remote command:
  • 51 were one-off calls to the other computer, each shaped slightly differently
  • 8 were attempts to open the connection itself

The log does not flag approvals for typed commands, so the real number was higher.

• 245 saved permission rules, most of them matching one exact command and nothing else. Choosing approve and remember had saved the exact text of each command, so the list grew and the prompts did not stop.

What we tried first

1. Approve and remember. It saves that one command only.
2. A rule for the exact command that opens the connection. The agent did not type it that way again.
3. Written instructions to use one connection. The agent followed them for typed commands but not for every one-off call.
4. Asking the agent why. It could not see the prompts either.

What worked

Codex's permission rules match the start of a command word for word, as the documentation describes. A rule for ssh host (ssh is the standard way to run a command on another computer) does not match the same command with an extra option or another tool's name in front of it. Three details decided the outcome:

• A third-party tool in our setup (it shortens command output) put its own name in front of every command, so a rule for ssh never matched tool ssh. We told the tool to leave remote commands alone.
• Codex's rule checker told us a command would match, and the real run disagreed. The checker only judges the text you give it, so we now test the exact command from the log.
• Commands typed into a live session on the other computer prompted every time in our first test. All 4 asked for approval, because typing into a session is a different kind of action from running a command, and we found no rule that covers it. We sidestepped it with one-shot calls that reuse a single shared connection, so nothing is typed into a session.

Note: the matching really is that strict. The real command contained a ~ (a shortcut for the home folder), and the rule written with it did not match.

In our test runs, a command that matched no rule ran in the agent's sandbox (a restricted area where it can work in the project folder but cannot reach other computers). That is a cautious default, and it is why that mismatch failed safely: in the test, the command ran in the restricted area, could not reach the other computer and stopped, instead of running unreviewed.

What changed

59 approvals in 324 commands before. 0 in 60 after.

In the first full working session after the changes, the agent ran 60 shell commands, 20 of them remote calls. The agent's log showed no approval requests, and the person at the keyboard saw no prompts either.

Where the real limit lives

We wanted a prompt to stay for dangerous commands such as sudo (run as administrator) and rm (delete). We tested sudo by running four commands through Codex itself, over the connection to the other computer. Three ran with no approval: hostname, uptime and sudo -n true (-n makes it fail instead of asking for a password) with quote marks around it, which succeeded as administrator. The fourth, sudo -n true without quote marks, was stopped for approval.

We had a rule that forces a prompt whenever sudo appears. It works on ssh host sudo true. It misses ssh host 'sudo true', because wrapping the command in quote marks makes the rule see one unbroken block of text instead of a sudo command.

Whatever that account can do, the agent can do.

So the limit has to live on the machine itself, and the strongest limit is the account the agent runs under. Administrator rights are for setup (installing software, creating accounts). An agent that works day to day should not keep them. The agent we are setting up to run unattended gets its own account with no administrator rights and no internet access.

What to take from this

• A constant prompt trains people to approve. Aim for fewer prompts, reserved for things that matter.
• Test the exact command the tool really runs, taken from its log, not the one you assume it runs.
• Read the agent's logs. They show what the agent cannot see about its own approvals.
• Decide where the limit lives. Whatever limits an AI agent has must live on the machine it works on, not in the tool's settings on yours.
• Give an agent administrator rights for setup only. Day to day, an automated agent should run without them.

If an agent runs a task in your business, the same approval fatigue applies to you. You Are the Bottleneck covers the owner's side.

This is how we set up agents for clients: the permissions, the logs and the checks, so the approvals that remain are the ones worth reading.

Tell us your task