Permissions

Nexma uses a role-based permission engine that scopes what each user — and each agent acting on their behalf — can read, write, or run. Permissions are checked on every Codex operation; there are no escape hatches.

Roles

A typical deployment defines four roles. Names are configurable per organization.

• Viewer. Read-only access to designated workspaces. No write, no Run, no

Solve.

• Designer. Read and write within assigned projects. Can invoke Solve. Cannot

approve published baselines.

• Reviewer. All Designer permissions plus the ability to approve a design as

baseline. Cannot delete projects.

• Admin. Full read, write, delete, and configuration. Manages roles and

approvals.

Authority flags

Every operation carries an authority flag:

• read — load a Codex file or query feed data.
• write — create or modify a Codex file.
• delete — remove a file or branch.
• run — invoke a deterministic computation.
• solve — invoke a solver family.
• approve — promote a design to baseline.
• share — publish a project externally.

The engine evaluates (role, authority, target) on every call. Targets can be scoped to workspaces, projects, branches, or specific paths.

Shadow mode

A new role or rule can run in shadow mode before it is enforced. Shadow records every decision the engine would have made without changing application behavior. Reviewers can audit the diff and promote when satisfied. This makes safe to tighten permissions on a live deployment.

Approval queues

Sensitive operations — promoting a baseline, sharing a project, deleting a branch — can be configured to enter an approval queue. The actor sees their request as pending; an approver receives it for review. Approval is logged with the reviewer's identity, the decision, and the rationale.

Subagent deny propagation

Jax can spawn subagents for parallel work. A subagent inherits the deny set of its parent — it cannot acquire authority the user does not have. This prevents an agent from "delegating around" a permission boundary.

Audit

Every permission decision is logged to the workspace audit stream — actor, authority, target, decision, timestamp. The audit stream is queryable from /permissions and exportable for compliance review.