The brief arrives with a next action and a do-not-do list, and everything the agent proposes lands as a proposal a human approves rather than a change already made. Authorization is per project, and a read-only token cannot even see the writing tools.
A remote server for ZERNO project context: the project brief, compiled agent memory, the task backlog, and structured ways to write back — task updates, triage proposals, intake tasks and session events.
- A project brief: current focus, next action, do-not-do list, memory index
- Compiled project memory plus recent events, assembled for one agent run
- Backlog listing with filters, and full detail on a single task
- Task fields and status patched, with the ICE score recomputed
- Triage proposals submitted and held for human approval rather than applied
- A review task filed from an agent's report
- Session summaries appended to project memory
- Tools/list filtered by scope — a read-only token sees only the four read tools
A ZERNO project and OAuth with PKCE; the client registers itself dynamically, so there is no static API key to paste. The endpoint is https://zerno.one/mcp over streamable HTTP, and user-scoped tokens need a project_slug such as zerno-one.
One command — codex mcp add zerno --url https://zerno.one/mcp