Where can I see what my AI agent may do?

An AI agent that works in your folder needs rules about what it may do there: read, write, run programs, reach the network. Snotra has those rules, and I think the model behind them is sound. What I’ve noticed while using it is a different problem: I can’t easily see the result. Last night I opened an issue about it, and this post is the reasoning behind that issue, before a single line of the fix exists.

The model, in two controls

Two things decide what a tool call may do, and they answer different questions:

• The mode decides whether Snotra asks. “Smart” lets reads through and asks for everything else, “Always ask” asks even before reading, “Auto” asks about nothing.
• The sandbox decides how far a program that Snotra runs can reach, whichever way the question was answered.

On top of that sit hard limits that no mode lifts, and rules you can add: a block always beats a permission. The infographic from the repository puts it on one page. That part I’m happy with.

Three questions an interface should answer

A model is only as good as a person’s ability to check it against their own situation. Three questions, asked while the agent is working:

1. What may Snotra do here, right now? In this workspace and this chat.
2. Why did it ask, or not ask, just now?
3. How do I change that, and how do I take it back?

Today you can answer each of them, but only after a search.

Eight places

I went through the app and counted every setting, state and approval that affects a tool call. They live in at least eight places: several cards in Settings › Tools, Settings › Permissions, Settings › MCP, and in the chat itself — the mode menu, the approval card, the tool log, and the shield in the folder panel. Every one of them made sense when it was added. Together they don’t. Some of what I found:

• Two tabs for one topic. “Tools” decides what the model can do at all, “Permissions” decides when it asks. To a user both are “what Snotra may do” — and the sandbox and program allowances, the parts with the largest effect, sit under “Tools”.
• Two ways of saving, side by side. On “Tools” some switches apply at once and the tool checkboxes only after Apply. “Permissions” applies at once.
• Approvals you can’t see. Approvals given for a session show up as a count and a button that deletes all of them. Nothing lists them, and nothing lets you take one back.
• Settings that vanish. The sandbox switch for a workspace and the program allowances disappear when the execution tools are off — so you can’t check their state before you switch the tools on.
• Facts without a handle. The sandbox status, the built-in list of sensitive paths and the warning about an unsigned rules file are shown, but you can’t act on them from where you read them.
• One thing, two controls. MCP tools can be switched off in Settings › Tools and again, per server, in Settings › MCP.
• No “effective” view. Nowhere does the app show the combined result of mode, rules, tools and sandbox for the folder that is open — which is precisely what the infographic explains in the abstract.

Some of these are quick fixes, and I’ll probably do those regardless: listing the session approvals, stopping the sandbox card from hiding, and making the text of “Reset all permissions” say everything it resets. But fixing eight rough edges leaves eight places. The requirement I’m holding myself to is stricter: every permission and every approval can be seen, and where it makes sense changed, in one place a user understands.

Four ways it could look

The issue is deliberately research first and code later. It asks for an inventory of every setting with its scope and source of truth, a comparison with how Claude Code, Cursor, VS Code’s Workspace Trust, the ChatGPT desktop app and macOS Privacy & Security present this, and at least three clickable mockups in light and dark, German and English. The starting points, none of them decided:

• A: One “Permissions” tab. Everything that governs rights moves in; “Tools” keeps only settings without a security effect, such as the interpreter path.
• B: An overview, “What Snotra may do here”. A summary per workspace on top — mode, isolation, what asks, what runs, what is blocked — with each line linking to the place where it changes.
• C: The matrix as the control. Risk class against mode as the central view, the effective value for the open workspace in each cell, and the rules and approvals that shape it beneath.
• D: A workspace panel reached from the shield in the folder panel and the mode menu, for what belongs to the workspace, while the settings dialog keeps the global parts.

Each of them has to survive the same questions: where do session approvals appear and how do you revoke one at a time; where do the settings that are hidden today go; how is “global”, “this workspace” and “this chat” made visible; and what does it look like with nothing configured, with two hundred rules, without encrypted storage, and on Windows, where there is no sandbox.

What must not change

A clearer surface is a good reason to redo the screens, and a bad reason to make security easier to loosen. So the issue names what every variant has to keep: anything that loosens protection still goes through a native confirmation dialog, nothing becomes easier to switch off than it is today, and the whole thing works with the keyboard and meets WCAG 2.1 AA.

Where you come in

The decision between the variants is mine to make, but I’d rather not make it in isolation. If you use Snotra, or any agent that asks before it acts, I’m curious about two things: which of the three questions above is hardest to answer in the tools you use, and which of the four variants you would look for first. The issue is open, and the Discussions are the place for the loose ends. Once a variant is chosen, the issue splits into implementation issues, and I’ll write about what came out.