The approval card is the moment where the agent's autonomy meets your decision. It is easy to turn it into a "yes" button pressed without looking. But the card does more than ask permission - it lets you read, edit and restrict the action before it happens, and that is its real value.
The naive move is understandable: the agent is busy, the card slows things down, and the hand reaches to confirm. The expectation is that the model proposes something reasonable and the card is a mere formality on the way to the result. From this grows the habit of approving quickly and broadly, especially when cards come one after another.
It breaks on the fact that people often confirm not what they read. A command is often almost right: the correct action, but the wrong working directory, an extra argument, too broad a glob, an unnoticed side effect. By approving in form, you sanction exactly the actual command, not your idea of it. So the first step at a card is not to press but to read: the command itself, the CWD, the arguments, the scope and the side effect. It is the working directory that deceives most often: a command harmless at the project root will touch the wrong files in another CWD, while an eye used to reading the command itself skips the directory.
The second step is that the card is editable, and that changes its role. The command can be fixed right in the card: narrow a path, drop a flag, change a directory. You can also, instead of editing by hand, describe the change you want, and a fast model rewrites the command - but the result comes back to you for review rather than running at once. There are keyboard actions too: approve, always-allow or reject without touching the mouse. The card is an editor of the decision, not only its switch.
The third step is to choose the grant's lifetime, and here the cost of a mistake grows with duration. A grant can be once, for the session, project-shared, project-local or global. The rule is simple: choose the shortest lifetime that is enough. Once remembers nothing; a session grant lives until the session ends; project and global grants are written to the config and survive a restart. The longer the lifetime, the further into the future the consequence of today's quick "yes" travels. The difference is especially tangible between project-shared and project-local: the former goes into the shared config and is picked up by colleagues, the latter stays with you, and confusing them means either imposing your rule on the team or losing it on the next clone.
One detail about the session grant matters for parallel work. In stable 3.7.16 a grant given for the session extends to the root agent and its subagents: having granted a scope once, you will not be re-prompted under each subagent. This is convenient and at the same time widens the radius - a session "yes" now covers not one executor but the whole tree. The version number here is not decoration: the behavior is dated and is checked against the current changelog.
Always-allow stands apart, because it is not a reply to the current agent but a policy change. Pressing it writes a rule into the config - and from that moment it applies to the future, not to one call. Before agreeing, open the file where the rule will land and make sure the written prefix or glob is not wider than the intent: the card often proposes a generalization, and a generalization easily turns out more generous than you wanted.
Why the card was made an editor rather than a plain yes or no. Because the alternatives are worse. A bare "no" stops the work and forces you to reformulate the whole prompt over one detail. A bare "yes" lets an almost-right command through whole. The ability to fix and restrict right in place keeps the agent moving but leaves the last word and the exact scope to the human - and that is the balance of autonomy and control. That is what sets a mature card apart from an "OK or Cancel" modal: it does not force a choice between full trust and a full stop.
You should verify a card decision not by what the agent "seems to have done" but by the action's trace. If you approved an edit, read the diff. If you approved a command, look at what it changed and where. If you pressed always-allow, open the config and reread the written rule with your eyes, not from memory of what the card proposed. A discrepancy between what you thought you approved and what was written is better caught at once than on the tenth session.
The typical failures are about confirming without looking. "The agent did the wrong thing" - the command was almost right and was skimmed. "It no longer asks" - always-allow was once pressed with a broad prefix. "The rule is too general" - a proposed generalization was accepted without opening the file. "A subagent acted unasked" - a session grant spread to the whole tree. The sign is the same: the card was closed faster than its command, scope and lifetime were read. Read these three fields, and almost every surprise disappears before the action.