Skip to main content
Before any agent tool executes, TYBA classifies the action into three levels. The color decides what happens: sail through, wait for you, or not even be offered.

Green

Passes on its own. You never see it.

Yellow

Waits for you. Can become “always” in this session.

Red

Waits for you. Never becomes “always”.
The underlying rule is when in doubt, yellow. Green is a closed list, not a heuristic — a command nobody anticipated does not pass on its own.

​
Green

The entire list. There is nothing else:
A build is not green. cargo build, bun install, make — all yellow, all wait for you. A build runs arbitrary scripts from dependencies; the green list is reads only.
Green is auto-approved always, with no way to turn it off. There is no setting that forces cat to ask for permission.

​
Red

Note the detail on rm: rm -rf, rm -fr and rm -r -f are all red. But rm file.txt is yellow — deleting a file inside the worktree is normal agent work. And the pipe into a shell is what catches curl ... | bash even when it’s written so that curl isn’t the first token.

​
Yellow

Everything else. Including an empty command.

​
Leaving the worktree paints it red

Regardless of the command, any token that starts with / or ~/ and resolves outside the session’s worktree escalates to red:
The exceptions are the system paths every command touches:
That is why cargo build 2> /dev/null stays yellow instead of escalating. The same goes for writes: writing inside the worktree is green; escaping it — via an absolute path, via ../, or through a symlink pointing outside — is red.

​
By tool

The network is always red because it is the way out: it is how content from your disk would turn into an outbound request. On Codex, apply_patch is classified by the worst path it touches — a patch with ten files inside the worktree and one outside is red.

​
What you answer

When something is waiting on you, TYBA notifies you and the session stays blocked until the answer.
Red has no “Always”. It is not the interface hiding the button — the core refuses to memorize any red, so there is no path for that combination to exist. When denying, you can write the reason. The text goes to the agent as the grounds for the refusal, and it usually tries another route instead of pushing.

​
What “Always” really means

“Always” is for this session and for this exact command. None of it reaches the disk.
  • It holds while the session lives. Closed, dead.
  • It matches the exact string: allowing cargo test does not allow cargo test --release.
  • It never accepts a red.
There is no persistent cross-session “always allow” today.

​
What never even gets asked

An agent pushing to main or master is refused by the core. It doesn’t become an approval request, it doesn’t show in the inbox, there is no button. The agent gets the error directly:
The refusal understands the variants — HEAD:main, +main and the like fall under the same rule.

​
Fail-closed

If the session dies with pending requests, all of them become denied. If the approval channel breaks, the default is deny. There is no path where an infrastructure failure turns into permission.

​
See also