Claude Code: cómo apagar el renderer fullscreen de forma permanente (y por qué el slash command no basta)

TL;DR — El renderer de pantalla completa de Claude Code se controla con la clave tui en ~/.claude/settings.json, con dos valores posibles: "default" (el clásico) y "fullscreen". No aparece en /config y no hay variable de entorno equivalente. Ponerlo explícitamente en "default" lo apaga para todas tus terminales y sesiones, de forma permanente. Y hay un motivo de peso para escribirlo en vez de dejarlo vacío: si la clave está sin definir, el propio CLI puede activarte el modo fullscreen solo.

1. El problema

Un día abres tu terminal y Claude Code ya no se comporta como un programa de línea de comandos: toma la pantalla completa, el scrollback deja de ser el de tu terminal, y el historial vive dentro de la aplicación. A algunos les encanta. A mí me estorbó.

El reflejo natural es ir a /config y buscar el interruptor. No está. El segundo reflejo es buscar una variable de entorno del estilo CLAUDE_CODE_DISABLE_ALGO. Tampoco existe una que haga exactamente eso.

Así que fui a buscarla donde sí estaba.

2. Arqueología en el binario

El CLI de Claude Code en Windows se instala como un ejecutable de unos 265 MB con todo el JavaScript empaquetado dentro. Eso significa que los strings siguen ahí y se pueden leer. Con grep -a (tratar el binario como texto) se puede extraer bastante:

cd "$APPDATA/npm/node_modules/@anthropic-ai/claude-code/bin"

# ¿Qué identificadores mencionan "renderer"?
grep -a -o -E "[A-Za-z_]{0,24}[Rr]enderer[A-Za-z_]{0,24}" claude.exe | sort -u

Eso devuelve cosas como rendererMode, getRendererModeForAnalytics, defaultRenderer… pistas, pero nada configurable. El hallazgo llegó al buscar textos de interfaz:

grep -a -o -E "\"[^\"]{0,60}[Ff]ull.?screen[^\"]{0,70}\"" claude.exe | sort -u

Entre los resultados aparecieron los que importaban:

"Set the terminal UI renderer (default | fullscreen)"
"Try the new fullscreen renderer?"
"To help us make fullscreen mode better, what made you switch back?"
"[default|fullscreen]"

Ese primer texto es la descripción de un slash command. Ampliando el contexto alrededor:

{ type: "local-jsx", name: "tui",
  description: "Set the terminal UI renderer (default | fullscreen)",
  argumentHint: "[default|fullscreen]" }

Ahí está: el comando es /tui. Y "Try the new fullscreen renderer?" es exactamente el diálogo que te lo ofrece.

3. Lo que dice el schema oficial

/tui resuelve el problema en caliente, pero yo quería saber dónde queda guardado. Buscando la definición del setting apareció el schema, que es la documentación de verdad:

tui: v.enum(["default","fullscreen"]).optional().describe(
  'Terminal UI renderer. "fullscreen" uses the flicker-free alt-screen renderer ' +
  'with virtualized scrollback (equivalent to CLAUDE_CODE_NO_FLICKER=1). ' +
  '"default" uses the classic main-screen renderer.'
)

Traducido: fullscreen usa el renderer de alt-screen sin parpadeo con scrollback virtualizado —equivalente a CLAUDE_CODE_NO_FLICKER=1— y default usa el renderer clásico sobre la pantalla principal.

Y buscando dónde se persiste apareció la llamada:

await yi("userSettings", { tui: "fullscreen" })

userSettings es ~/.claude/settings.json. O sea: es una clave normal de tu configuración de usuario, que puedes escribir tú mismo.

4. La solución

Una línea en ~/.claude/settings.json (en Windows, C:\Users\<tu-usuario>\.claude\settings.json):

{
  "model": "opus[1m]",
  "tui": "default"
}

Es una clave de primer nivel, hermana de model, env, hooks o permissions. No la anides.

El renderer se elige cuando arranca el proceso, así que el cambio aplica a partir de la siguiente sesión. Si lo quieres de inmediato en la sesión que ya tienes abierta, teclea:

/tui default

El CLI se relanza en ese momento. Pero ojo: eso resuelve el ahora; el archivo es lo que lo hace permanente.

5. El detalle que justifica escribirlo

Aquí está la parte interesante, y la razón por la que no basta con “no activarlo nunca”.

Revisando el código encontré esta rama, en el flujo que muestra el diálogo de retención (el que aparece cuando alguien vuelve al modo clásico):

O("tengu_fullscreen_downsell_shown", { seen_count: e }),
e >= Rff && eo().tui === void 0) {
  let { error: t } = await yi("userSettings", { tui: "fullscreen" });
  if (t) { w(`fullscreen downsell graduation persist failed: ...`) }

Léelo con calma: cuando el contador llega a cierto umbral y tui está sin definir (=== void 0), el CLI escribe tui: "fullscreen" en tus settings por su cuenta. El propio mensaje de error interno lo llama “fullscreen downsell graduation”.

La conclusión práctica: dejar la clave vacía no es lo mismo que tenerla apagada. Vacío significa “aún no has decidido”, y ese estado puede resolverse solo. Escribir "default" de forma explícita cierra esa puerta, porque la condición tui === void 0 deja de cumplirse.

Aclaración honesta: esto sale de leer JavaScript minificado dentro del binario, no de documentación pública. La lectura me parece clara, pero es una inferencia sobre código ofuscado, no una cita oficial.

6. Verificar que quedó bien

Después de editar, confirma que el JSON sigue siendo válido y que no rompiste nada más. Un settings.json malformado desactiva en silencio todas las configuraciones de ese archivo, así que este paso no es opcional:

node -e "
const s = require(process.env.USERPROFILE + '/.claude/settings.json');
console.log('JSON válido OK');
console.log('tui =', JSON.stringify(s.tui));
console.log('valor en el enum:', ['default','fullscreen'].includes(s.tui));
console.log('hooks intactos:', Object.keys(s.hooks || {}).join(', '));
"

7. Alcance: ¿aplica a todas mis terminales?

Sí. ~/.claude/settings.json son los user settings: valen para cualquier sesión, en cualquier terminal (CMD, PowerShell, Git Bash, la integrada de VS Code) y en cualquier proyecto. Sobreviven reinicios y actualizaciones del CLI, porque el archivo no se toca al actualizar.

Conviene confirmar que nadie te lo pise. El orden de precedencia es:

Una comprobación rápida:

grep -rl '"tui"' ~/proyectos --include="settings.json" --include="settings.local.json"

Sin resultados, nadie te lo sobrescribe.

8. Ajustes vecinos que quizá busques

Durante la excavación aparecieron otras variables relacionadas, útiles si tu problema real es de parpadeo o de scroll:

Esas dos últimas explican una confusión común: si estás en modo clásico y activas esas opciones en /config, no notarás ningún cambio. No están rotas; simplemente no aplican a tu renderer.

Y si lo que se te rompió es el scroll con la rueda del ratón, ese es otro interruptor distinto —CLAUDE_CODE_DISABLE_MOUSE— y tiene su propia historia: Cuando arreglar la fuga de tokens te rompe el scroll.

9. Lo que me llevo

Tres cosas, más allá de la configuración concreta:

1. Cuando una opción no está en el menú, suele existir igual. Los strings del binario son documentación involuntaria, y grep -a los lee sin necesidad de herramientas especiales.
2. El schema es mejor documentación que el README. Ahí están el tipo, el enum de valores válidos y una descripción escrita por quien programó la función.
3. En configuración, “vacío” y “apagado” no son lo mismo. Un valor ausente es una decisión pendiente, y el software tiene todo el derecho a resolverla por ti. Si te importa, escríbelo.

Entorno probado: Windows 11 Pro (10.0.26200) · Claude Code 2.1.220 (Opus 5). Los nombres de variables minificadas (yi, eo, Rff) cambian entre versiones; los textos y las claves de configuración, no.