Ajustes comunes del asiento
UI de terminal que maneja Orchemax, allowlists MCP/tools del vendor, asientos con login/plan (sin API key), modelo de OpenClaude, dontAsk vs bypassPermissions, wire de Notification y tope de turnos.
Objetivo#
Fricción del asiento que sí configuras tú (modelo, permisos, notify, allowlists del vendor, account vs gateway).
Ya no necesitas trucos de mouse ni Quick Edit de OpenCode / Claude Code.
Orchemax maneja el path de terminal en Windows (ConPTY / attach nativo,
scroll por capacidad, detach/reattach, orch seat * en vivo).
UI de terminal (asientos Windows) — lo maneja Orchemax#
Un orch <agent> interactivo en Windows debe sentirse como el CLI del vendor
solo: teclear, rueda, seleccionar/copiar y prompt limpio al salir. Orchemax lo
hace sin que pongas OPENCODE_DISABLE_MOUSE, toques Quick Edit ni pegues knobs
de mouse del vendor.
agents:
seat_host: true # default en Windows; ORCH_SEAT_HOST=0 lo apaga
| Capacidad | Qué pasa |
|---|---|
| Host-scroll (familia Claude-settings, p. ej. OpenClaude) | Hold ConPTY; scrollback VT del host; End sigue; DEC mouse off para seleccionar/copiar en WT |
| Child-scroll (OpenCode + BYO desconocido) | Attach nativo — el TUI del vendor mueve el scroll; Orchemax apaga Quick Edit y no fuerza alt-screen para que puedas teclear |
| Estado en vivo | orch seat status|wait|read|report (+ MCP seat_*) sobre .orch/seats/ — no scraping como política |
| Detach / reattach (solo hosted hold) | La LLM llama seat_detach si dejas la UI; vuelves con orch <agent> y Orchemax reengancha. Sin lateral mux. Native-child no puede detach |
Un orch <bin> sin entrada de catálogo cae en child-scroll — no es una
whitelist de nombres. SeatScroll / HookLayout son hints opcionales.
orch seat report <session> --state working|ready|blocked|exit
orch seat status <session> --json
orch seat wait <session> --until blocked --timeout 120
orch seat read <session> --lines 80
orch seat read <session> --deep --lines 120
Tail: .orch/seats/<session>.tail.txt mientras corre. Hints como
maybe_blocked nunca satisfacen wait --until blocked. Resume:
--resume-ref / ORCH_RESUME_REF.
Solo escape hatch (seat_host: false / ORCH_SEAT_HOST=0):
agents:
disable_mouse: off # default — el agente maneja el mouse
# disable_mouse: clicks # clásico Claude + DISABLE_MOUSE
# disable_mouse: all # mismos knobs Claude; Orchemax nunca fija OPENCODE_DISABLE_MOUSE
Env: ORCH_AGENT_MOUSE=off|clicks|all. Mejor dejar seat_host encendido.
El TUI de un CLI pelea con el host de terminal#
Quién manda la rueda se decide por agente, no por familia: child deja en paz
el TUI de pantalla completa y el mouse del agente, host le entrega el
scrollback a Orchemax y apaga el mouse del agente.
El mismo binario claude sirve a todos los talleres de una máquina, así que esto
es de la máquina. Se escribe una sola vez en seats.yaml de la casa de
máquina (orch home imprime la carpeta):
seat_scroll:
claude: child # conserva su propio mouse y pantalla alterna
openclaude: child
Un taller lo pisa por preset cuando alguno necesita otra cosa:
agents:
seat_scroll:
opencode: host # entrega la rueda al host, solo en este taller
Orden: el orch.yaml del taller, luego seats.yaml, luego la entrada de
catálogo del agente — así que un CLI que nadie catalogó conserva su TUI. Nombra
al agente aquí en vez de recurrir a disable_mouse, que habla por todos.
Exportar el chat fuera del asiento#
orch session transcript
orch session transcript --open
El picker de OpenClaude siempre vuelve (p. ej. orchemax/pareto)#
Causa: en ~/.openclaude/settings.json quedó pinneado env.OPENAI_MODEL.
OpenClaude mezcla settings.env al proceso, y ese valor pisa el campo
model y el picker de la UI.
Arreglo: enruta el gateway en env y elige el modelo solo con model:
{
"model": "orchemax/deepseek-v4.1-flash",
"env": {
"CLAUDE_CODE_USE_OPENAI": "1",
"OPENAI_BASE_URL": "http://127.0.0.1:8788/v1"
}
}
No pongas OPENAI_MODEL (ni un orch_gk_… pegado) en env si lanzas
con orch openclaude — la sesión inyecta la clave, y orch openclaude
limpia un env.OPENAI_MODEL persistido al arrancar.
Sin prompts de permiso (Chair y workers)#
Bajo Orchemax el taller es el perímetro (locks, guards, worktrees) — no el diálogo “¿Permitir esta herramienta?” del vendor en cada Bash/Edit/MCP.
Mejor default (lo que cablea Orchemax):
| Asiento | Cómo se auto-aprueba |
|---|---|
| Chair interactivo (Claude / OpenClaude / agy) | Flag CLI --dangerously-skip-permissions en el orch <agent> por defecto |
| Worker headless (misma familia) | Misma flag en el preset headless; dispatch también la inyecta si falta |
| Worker OpenCode | opencode run --auto |
| Chair + worker Cursor | Interactivo: --approve-mcps --trust. Headless: --force --trust --approve-mcps (la whitelist MCP de Cursor se reinicia cuando Orchemax reescribe .cursor/mcp.json) |
| JSON Claude-settings | orch guard wire pone permissions.defaultMode: bypassPermissions si falta, y siempre permite mcp__orch__* |
Un Chair que lanza un worker no arrastra una cadena de prompts humanos — el worker no tiene teclado. Si un asiento headless choca con un muro de permiso, Orchemax marca exit 126.
Prefiere bypassPermissions sobre dontAsk (dontAsk niega lo que no esté
en permissions.allow):
"permissions": {
"defaultMode": "bypassPermissions",
"allow": [
"mcp__orch__*",
"Bash(*)",
"Read(*)",
"Edit(*)",
"Write(*)",
"MultiEdit(*)"
]
}
orch guard wire --openclaude / --claude mete mcp__orch__* y rellena
bypassPermissions cuando falta defaultMode. Reinicia el asiento tras
editar. Si quieres prompts del vendor, pon un defaultMode explícito (p. ej.
default) — Orchemax no lo pisa.
Allowlists del vendor / muros de aprobación MCP#
Patrón: Orchemax reescribe el MCP/config del asiento en cada launch
(ORCH_SESSION, rol, rutas). Muchos CLIs guardan una allowlist o hash
local de ese archivo. Si el hash cambia, el vendor vuelve a pedir Approve —
aceptable en un IDE de escritorio, fatal en workers headless, y en algunos TUI
de Windows el diálogo se cuelga tras elegir (hay que matar la terminal).
Esto no es una allowlist de nombres de Orchemax. Usa la flag nativa de
auto-aprobación en presets interactivo y headless. En un BYO, pon la misma
clase de flag en agents.interactive.<id> y agents.cmds.<id>.
| CLI / superficie | Qué re-pregunta | Default / arreglo Orchemax |
|---|---|---|
Cursor (cursor-agent) |
Aprobación MCP de proyecto (mcp-approvals.json hashea la entrada; Orchemax pone ORCH_SESSION en .cursor/mcp.json → hash nuevo casi cada seat) |
Interactivo: cursor-agent --approve-mcps --trust. Headless: -p … --force --trust --approve-mcps |
| Claude / OpenClaude / agy | “¿Permitir?” por tool | --dangerously-skip-permissions en interactivo + headless |
Claude-settings dontAsk |
Tools MCP fuera de permissions.allow |
Permitir mcp__orch__*; preferir bypassPermissions (sección arriba) |
| OpenCode | Aprobación de tools en run |
opencode run --auto |
| agy MCP | Sin MCP por workspace | orch guard wire --agy --scope user --allow-user-scope una vez |
| BYO | Trust / yolo / approve-mcp (docs del vendor) | Flags nativas en orch.yaml; nunca depender de un humano en el worker |
Cursor: el TUI de Approve MCP se congela en orch cursor#
Síntoma: el TUI de aprobación MCP se cuelga en “Applying your selection…”.
Arreglo: el default interactivo ya es cursor-agent --approve-mcps --trust
(actualiza orch si el tuyo es viejo). Override en orch.yaml o ver
configure-agents y troubleshooting.
Asientos con login / plan (sin API key)#
Los asientos con plan del vendor mantienen su login — el tráfico de modelos
no pasa por el gateway local. orch setup siembra
agents.auth.<preset>: account para Cursor / Claude / Codex / agy / Gemini;
los CLI de API-key reciben gateway.
No pongas claves de proveedor en keys.env para asientos de plan, y no
corras orch gateway connect para sustituir el login. Solo override cuando
lo quieras:
agents:
auth:
claude: gateway # API key Anthropic vía gateway — no el login Pro/Max
Matriz completa: configure-agents, gateway-keys-and-connect.
OpenClaude necesita respuesta — no hay toast#
orch guard wire --openclaude
OpenClaude lee .openclaude/, no .claude/. Abrir orch openclaude también
inyecta .openclaude/settings.local.json del proyecto. Prueba el canal:
orch notify test --desktop.
OpenClaude: /compact falla (manual y automático)#
Causa: compactModel (o el modelo principal si no hay) es un id flash/
reasoning (p. ej. orchemax/deepseek-flash-latest). Esos modelos suelen
mandar el resumen en reasoning; OpenClaude solo lee content → “no summary
text” / safety limit de mensajes.
Arreglo: orch openclaude reescribe un compactModel débil en
~/.openclaude.json a orchemax/pareto (override ORCH_OPENCLAUDE_COMPACT_MODEL,
opt-out =off). Luego seat nuevo (/new) y /compact otra vez — un hilo
ya cortado por el safety stop casi nunca se recupera in-place.
"compactModel": "orchemax/pareto"
Puedes dejar flash para el chat; el compact necesita un modelo con content
estable.
OpenClaude se detiene a los 50 turnos#
openclaude --max-turns 0
# o OPENCLAUDE_MAX_TURNS=200
O en orch.yaml:
agents:
interactive:
openclaude: openclaude --max-turns 0