Permission Mode Lives in APX, Not APC

APC is the portable context layer. APX is the daily-use runtime and tooling layer. That split is the reason permission mode belongs in APX, not in the repo.

Permissions are not project truth. They are machine policy.

That sounds small, but it matters. A repository should travel cleanly across laptops, desktops, and runners. A permission setting should not force the same risk level everywhere the repo lands. If you bake permission state into APC, you make the project less portable and mix local trust with shared context.

What APX actually stores

The APX code makes the boundary explicit. Permission mode lives in ~/.apx/config.json, not in .apc/.

The available modes are:

• total - run every tool without confirmation
• automatico - allow safe reads and safe shell work directly; ask for confirmation on destructive, outbound, runtime, MCP, or filesystem-changing actions
• permiso - run only tools in allowed_tools directly; everything else needs confirmation

automatico is the default. That is a sane choice for daily use because it keeps the runtime usable without making every action manual.

Why this cannot live in APC

APC is the portable layer: project metadata, agents, skills, MCP hints, and durable project context. That content should be reviewable in git and stable across tools.

Permission mode is different. It depends on:

• who owns the machine
• whether the machine is personal or shared
• whether the current task is exploratory or high-risk
• how much trust the user wants the runtime to have today

Those are runtime facts, not project facts.

If you move permissions into APC, two bad things happen:

1. Clone the repo somewhere else and you inherit a policy that may not fit the new machine.
2. Edit permission state in git and you turn a local safety choice into shared project baggage.

That is the wrong direction. The repo should describe the work. APX should decide how much power the local runtime gets while doing it.

The guard is runtime code, too

APX enforces this boundary in code, not just in docs.

createPermissionGuard() reads globalConfig.super_agent.permission_mode plus allowed_tools, then blocks or allows a tool call based on the active mode.

The rule is simple:

• total skips the guard
• automatico blocks dangerous actions unless the user confirms them
• permiso blocks everything except the explicitly allowed tools

That is a useful shape because it matches real work. Reading a file is not the same as mutating a repo. A safe lookup is not the same as firing a runtime or touching an MCP connection.

APX keeps that distinction in the runtime where it belongs.

Practical example

Say you are on a personal laptop and want APX to be mostly hands-off. automatico fits.

Now imagine the same repo opens on a shared workstation, or inside a setup where only a small tool set should run freely. permiso may be the right fit there.

Same APC project. Different APX policy.

That is exactly the point: the project stays unchanged, but the local runtime can adapt to the machine it is running on.

The deeper rule

A quick test helps decide where a setting belongs:

• If it answers "what is this project?" it belongs in APC.
• If it answers "what may this machine do right now?" it belongs in APX.

Permission mode clearly falls in the second group.

That boundary keeps APC portable and reviewable. It keeps APX local and honest. And it keeps a shared repo from accidentally carrying one person's safety choices into every future clone.

Bottom line

Permissions are not part of the portable project contract.

They are runtime policy. APX owns them. APC stays clean.

That is the split that keeps the system sane: one repo, many machines, different trust levels, no confusion about where the decision lives.

Comments

[Alex Shev]

This split makes sense. Project context should be portable truth; permission mode is local machine policy. Mixing them makes the repo look authoritative about a boundary it cannot actually enforce.