Permissions
Every provider, agent, automation and JARVIS itself acts inside the permission model you choose. Nothing is above it.
KalCode is in private development. This page describes the product as it is designed; details may change before release.
How a decision is made
When an agent wants to do something — read a file, run a command, install a package, push a branch — KalCode classifies the request by scope, then evaluates it against your active permission mode, your standing rules, and the workspace and thread it belongs to. The result is one of three outcomes:
- Allow — the action runs. Consequential actions are recorded in the audit log.
- Ask — the thread pauses and the request appears on the Dashboard for your decision.
- Deny — the provider receives a denial and the action does not run.
Permission modes
| Mode | Intent | Default behaviour |
|---|---|---|
| Plan | Read and plan; no modification. | Reads are allowed. Writes, commands and network changes are denied or asked. |
| Approve | The default. Safe work proceeds; work that needs authority pauses. | Workspace reads are allowed. Writes and commands ask unless a rule covers them. |
| Auto | Approve what your policy covers automatically. | Covered actions are allowed; everything else still asks. Always-ask scopes always ask. |
| Bypass | Broad local execution authority. | Local workspace actions are allowed. Pushing, production deploys, cloud changes, spending and sending messages still follow their own rules. |
| Custom | Named rule sets, such as “Code reviewer” or “Local builder”. | Per-scope allow, ask, deny or never. |
Bypass requires your explicit selection, shows a warning, and keeps a persistent indicator on screen while it is active. It is never enabled by an agent or by JARVIS.
Your choices when asked
When a request needs your decision you can deny it, approve once, approve for the thread, approve for the workspace, or allow it with a rule that covers similar requests in future.
Requests expire when their thread stops, the provider process exits, or a newer request supersedes them. An expired request is shown as expired and cannot be approved.
Scopes
Requests are classified into scopes such as:
filesystem.read,filesystem.write,filesystem.outside_workspaceterminal.read_only,terminal.execute,package.installgit.read,git.commit,git.pushnetwork.docs,network.other,browser.navigate,browser.interactcredentials.access,messaging.send,deploy.production,cloud.modify,billing.spend,destructive
Across different providers
You see one permission experience, but each provider exposes its own controls. For every mode, each provider adapter declares whether its mapping is exact, approximate, or unsupported. KalCode never silently grants more authority than your mode implies: if a provider cannot express a mode exactly, KalCode uses the closest stricter setting and shows you the difference.
Audit
Approvals, denials, mode changes and Bypass activation are written as events to the local event log, where they cannot be edited.