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

Relacionado#