Granting and checking access
Development reference · View source
:mcp opens MCP permissions, selecting an existing granted identity when
available. An explicit :mcp codex always selects that identity. The overlay
shows the exact workspace, identity, whether access is enabled or not yet
granted, whether it is remembered, and how many readers are connected. A
connected reader identifies a local connection, not a verified agent process.
:context-access remains an alias for existing configurations.
| Key | Permission or action |
|---|---|
1 | Read terminal output |
2 | Editor-context read permission; MCP exposes buffer reads |
3 | Edit and append to buffers; also enables buffer reads |
4 | Propose terminal text; also enables terminal reads |
r | Remember this exact workspace’s grant |
n | Next known identity; discards unapplied choices |
x | Revoke the selected identity immediately |
j / k | Page through longer reviews |
Tab then Enter | Select Apply permissions and apply |
Esc | Close without applying |
Turning off a read permission also turns off its dependent write permission. The remembered checkbox reflects the current grant when reopened. Without it, the grant lasts until the owning editor or persistent host exits. Applying a change disconnects existing readers, so agents must rediscover their targets.
Granting, changing, and revoking need physical input from the active Runyte frontend. Repeated input, pasted text, macros, and MCP clients cannot approve access or terminal text. Each terminal proposal still needs its own native approval and inserts text without Enter.
The server works with ide-mode and mux-mode workspaces on Linux, macOS, and Windows. Detached hosts support content reads and buffer edits, but cannot approve terminal insertion until a native frontend is attached.