Variables de entorno: esa fila de 'interruptores generales' ocultos detrás

📚 Navegación de la serie: El artículo anterior 41 Tareas en paralelo te enseñó cómo dividir el trabajo para hacer que varios Claude se ejecuten al mismo tiempo. Este artículo profundiza bajo la superficie: esos 'interruptores generales' que controlan cómo se conecta Claude Code a los modelos, cuánto dura el tiempo de espera o si se deben reportar datos se gestionan mediante variables de entorno. No están en ningún menú, se esconden en tu shell y en settings.json. Hoy conoceremos toda esta fila de interruptores y aprenderemos a ajustarlos.

Se dice que las variables de entorno son "algo que solo tocan los jugadores avanzados", pero para ser sinceros, esa afirmación ha perjudicado a muchos.

Demasiada gente depende de ingresar comandos /model manualmente en la conversación o ajustar los tiempos de espera uno por uno cada vez que inician una sesión, para luego tener que repetir todo en la siguiente sesión. Si les preguntas por qué no lo configuran de forma permanente de una vez, la respuesta suele ser: "Las variables de entorno suenan muy complejas y temo romper algo".

Pero si revisas los cuarenta y un artículos anteriores: el artículo 04 configurando las API keys, el artículo 05 integrando modelos locales, el artículo 19 gestionando el contexto y el artículo 21 desactivando la telemetría... en el fondo, casi todo esto se apoya en el mismo mecanismo subyacente: las variables de entorno. Ya las has estado usando, solo que nadie las había expuesto juntas de esta manera.

Pongámoslo así: las variables de entorno no son solo para "usuarios avanzados", sino que son esa fila de interruptores generales que configuras una vez y te benefician de por vida. Temerles es simplemente porque nadie te ha dicho cuáles son los interruptores comunes o cuáles serían las consecuencias si los configuras mal. Hoy disiparemos ese temor.

Al terminar este artículo, obtendrás:

• Una explicación simple de qué controlan exactamente las variables de entorno en Claude Code y por qué vale la pena dedicar diez minutos a entenderlas.
• Una tabla comparativa para saber cuándo usar cada uno de los tres métodos de configuración (temporal de shell / permanente en archivo de configuración de shell / campo env de settings.json).
• Qué alcance tiene cada uno de los cuatro tipos de archivos settings.json, y cuál debe entrar a git y cuál no (conectando con el artículo 31).
• Una lista con las variables de entorno más importantes de conocer: conexión, tiempos de espera, privacidad y directorios de configuración, junto con sus valores por defecto y advertencias.
• Las reglas de prioridad que definen quién manda cuando algo se puede configurar tanto con variables de entorno como con campos de configuración.
• Un ejercicio práctico paso a paso con los resultados esperados para configurar una variable y verificar que realmente funcione.

---

01 Entiende primero: qué controlan realmente las variables de entorno en Claude Code

Para empezar, la conclusión: las variables de entorno son un conjunto de interruptores de tipo "clave-valor" que lee Claude Code al iniciar para definir comportamientos básicos como la conexión al modelo, la autenticación, los tiempos de espera y si se deben reportar datos.

La mayoría de las funciones que has usado antes (cambiar el modelo con /model, agregar servicios con claude mcp add o cambiar configuraciones con /config) son para "ajustar temporalmente algo dentro de la conversación". Pero hay ciertos comportamientos que deseas que se apliquen automáticamente en cada inicio sin tener que configurarlos manualmente cada vez: por ejemplo, "usar siempre mi dirección de proxy personalizada", "ampliar el tiempo de espera de todas las solicitudes a 20 minutos" o "nunca reportar telemetría desde esta máquina". Estas reglas básicas que defines para que no cambien son las que gestionan las variables de entorno.

La documentación oficial lo define en una sola frase:

Las variables de entorno pueden controlar el comportamiento de Claude Code, como la selección del modelo, la autenticación, el enrutamiento de solicitudes y la activación de funciones.

Analogía: botones preestablecidos en una cafetera. En una cafetera con preajustes, puedes ajustar manualmente cada taza: la cantidad de agua, la intensidad o si deseas agregar leche cada vez; o puedes guardar tu taza favorita como "mi preajuste" para que la máquina recuerde los parámetros y la prepare con un solo botón. Las variables de entorno son esto último: fijan las configuraciones que quieres aplicar siempre para que Claude Code las lea al iniciar, evitándote tener que ajustarlas manualmente cada vez.

En escenarios reales, es muy probable que pienses en ellas en estas situaciones:

• "He integrado DeepSeek y no quiero especificar el modelo manualmente cada vez": escribe el modelo y la dirección en las variables de entorno (el mecanismo subyacente del artículo 05 es este).
• "La red de la empresa es lenta y el tiempo de espera predeterminado de 10 minutos no es suficiente": amplía el tiempo de espera con una sola variable.
• "Esta es una máquina de la empresa y los requisitos de cumplimiento exigen no reportar telemetría": desactívala directamente con una variable (mencionado en el artículo 21).
• "Tengo cuentas de trabajo y personales y quiero separarlas para evitar interferencias": cambia el directorio de configuración con una variable.

¿Te das cuenta? Todas estas son necesidades de "configurar una vez y aplicar a largo plazo". Las variables de entorno nacieron para este tipo de necesidades.

💡 Resumen rápido: las variables de entorno son un conjunto de interruptores clave-valor que lee Claude Code al iniciar para controlar la conexión, autenticación, tiempos de espera y privacidad. Su valor radica en fijar las configuraciones preferidas de una vez para no tener que ajustarlas manualmente cada vez.

---

02 Dónde configurarlas: tres métodos, desde "solo esta vez" hasta "permanente"

Una vez que sabemos qué controlan, la siguiente pregunta práctica es: ¿dónde se configuran? La respuesta es tres lugares, diferenciados por una sola línea: cuánto tiempo y a quién afecta la configuración actual.

La documentación oficial lo explica de manera directa:

Las variables configuradas en la shell solo son válidas durante esa sesión de terminal, mientras que las variables en los archivos de configuración se aplican cada vez que ejecutas claude.

Clasifico los tres métodos desde el menor al mayor alcance para que elijas:

Método 1: Configurar temporalmente en la shell (afecta solo a esta terminal)

Antes de iniciar claude, ejecuta un export en la terminal. Solo será válido para la ventana de terminal actual y desaparecerá al cerrarla.

macOS / Linux / WSL:

export API_TIMEOUT_MS="1200000"
claude

Windows PowerShell:

$env:API_TIMEOUT_MS = "1200000"
claude

Este método es ideal cuando "solo quiero probar esta vez": ampliar un tiempo de espera temporalmente o cambiar una dirección de forma puntual; cierras la terminal al terminar y no queda rastro.

Método 2: Escribir en el archivo de configuración de la shell (se aplica en cada inicio en esta máquina)

Si quieres que se aplique automáticamente cada vez que abras una terminal, agrega esa línea export al archivo de configuración de tu shell. En Mac, por defecto es ~/.zshrc, y en muchos sistemas Linux es ~/.bashrc:

# Agregar al final de ~/.zshrc
export API_TIMEOUT_MS="1200000"

Se aplicará al abrir una nueva terminal (o al ejecutar source ~/.zshrc). Este es el método para aplicar la configuración de forma global en todos los proyectos y terminales de tu máquina.

En Windows, para hacerlo persistente, usa setx API_TIMEOUT_MS "1200000" (CMD) o [Environment]::SetEnvironmentVariable("API_TIMEOUT_MS", "1200000", "User") (PowerShell) y abre una nueva terminal para que se aplique.

Método 3: Escribir en el campo env de settings.json (sigue a la configuración, independientemente de cómo se inicie)

El tercer método, y el más recomendado, es escribir en la clave env dentro de settings.json. La documentación oficial detalla su beneficio:

Claude Code las lee directamente del archivo al iniciar, por lo que se aplicarán sin importar cómo inicies claude.

{
  "env": {
    "API_TIMEOUT_MS": "1200000",
    "BASH_DEFAULT_TIMEOUT_MS": "300000"
  }
}

La ruta y escritura de este archivo ya se explicaron en el artículo 31 sobre settings.json. Aquí solo debes recordar: env es el espacio reservado específicamente para variables de entorno; al escribir las variables aquí, no importa cómo ejecutes claude, siempre las leerá.

Compara los tres métodos para elegir el adecuado:

Método de configuración	Alcance de efectividad	¿Se mantiene al cerrar la terminal?	Ideal para
export temporal en shell	Solo la terminal actual	❌ No	"Solo quiero probar esta vez"
Escribir en ~/.zshrc, etc.	Todas las terminales de la máquina	✅ Sí	"Aplicar globalmente en mi máquina personal"
Escribir en env de settings.json	Depende del alcance del archivo	✅ Sí	"Vincular al proyecto/equipo, aplicarse al iniciar"

Un hábito práctico: para verificar temporalmente si una variable funciona, usa export en la shell; una vez confirmada, muévela al campo env de settings.json. ¿Por qué preferir settings.json sobre ~/.zshrc? Debido a la clasificación de archivos de la siguiente sección: settings.json te permite controlar con precisión si la variable es solo para ti, para todo el equipo o solo para este proyecto, algo que ~/.zshrc no puede distinguir.

💡 Resumen rápido: Los tres métodos se clasifican por su alcance: export temporal en la shell (una sola vez), escribir en ~/.zshrc (global en la máquina) y escribir en env de settings.json (sigue a la configuración e independiente del inicio); usa el primero para pruebas y el tercero para permanencia.

---

03 Las cuatro clases de archivos settings.json: alcance y control de git

Mencionamos en la sección anterior que el campo env de settings.json es la opción recomendada, pero hay una trampa común para principiantes: settings.json no es un solo archivo; existen cuatro clases de archivos, y escribir la variable en uno u otro define a qué usuarios afectará.

Esto ya se detalló en el artículo 31, pero lo reforzamos aquí desde la perspectiva de las variables de entorno, ya que las consecuencias de equivocarse de archivo son reales: podrías subir accidentalmente a git una dirección de proxy con tu token personal, afectando a todo tu equipo.

Analogía: cartelera de anuncios de la empresa vs. nota adhesiva personal. Si el departamento de finanzas imprime "límite de taxi de 50" y lo coloca en la cartelera, todos en la empresa deben cumplirlo; esa es una regla pública. Si tú escribes en una nota adhesiva en tu escritorio "no reportar mi café de este mes", es una nota personal solo para ti. Configurar las variables en uno u otro archivo es elegir entre la cartelera o la nota adhesiva.

La tabla oficial muestra a quién afecta cada clase de archivo:

Archivo	Se aplica a
~/.claude/settings.json	A ti, en todos los proyectos
.claude/settings.json	A todos los que trabajan en el proyecto, guardado en el control de código fuente
.claude/settings.local.json	A ti, solo en este proyecto, no guardado
Configuración hospedada	A todos en tu organización, desplegada por administradores

En términos sencillos:

• ~/.claude/settings.json: en tu directorio principal ("solo para mí, en todos los proyectos"). Ideal para tus preferencias personales.
• .claude/settings.json (raíz del proyecto): "para todos en este proyecto" y se guarda en git, por lo que tus compañeros lo obtendrán al clonar. Ideal para reglas unificadas del equipo.
• .claude/settings.local.json (raíz del proyecto): "solo para mí, solo en este proyecto" y no se guarda en git (la extensión .local se ignora por defecto). Ideal para credenciales personales o configuraciones temporales propias.
• Configuración hospedada: distribuida globalmente por los administradores para toda la organización; no la modificas tú.

Es muy fácil cometer un error aquí. Al conectar una pasarela personalizada, para ahorrar tiempo podrías escribir ANTHROPIC_BASE_URL junto con tu token de acceso personal en el archivo .claude/settings.json de la raíz del proyecto y hacer un git commit. Si no revisas el diff antes de subirlo, tendrás un problema: habrás expuesto tu clave personal a todos los que tengan acceso al repositorio. Recuerda esta regla de oro: cualquier variable de naturaleza personal (claves privadas, directorios locales) debe ir en el archivo .local que no se sube a git; solo las configuraciones que deben compartir todos los miembros del equipo deben ir en .claude/settings.json.

Naturaleza de la variable	Archivo donde escribirla
Preferencia personal, común para todos los proyectos	~/.claude/settings.json (directorio principal)
Unificada para el equipo, compartida en el proyecto	.claude/settings.json (se sube a git)
Personal, con credenciales, solo para este proyecto	.claude/settings.local.json (❌ no se sube a git)

💡 Resumen rápido: settings.json se divide en cuatro clases que definen a quién afecta la variable: el directorio principal afecta a uno mismo, el de la raíz del proyecto se sube a git y afecta a todo el equipo, y el .local no se sube a git y solo te afecta a ti; nunca coloques credenciales personales en archivos que se suban a git.

---

04 Las variables más importantes: conexión, tiempos de espera, privacidad y directorios

La tabla de variables de entorno oficial es extremadamente larga; contiene cientos de variables, desde exportadores de OpenTelemetry hasta configuraciones de AWS Bedrock, la mayoría de las cuales nunca usarás. Por ello, no listaremos todas, sino solo la decena que realmente usarás, agrupadas en cuatro categorías y explicando qué hacen, su valor predeterminado y advertencias.

Grupo 1: Conexión y autenticación (cómo conectarse al modelo)

Este grupo es la base de los artículos 04 y 05. Tres variables principales:

ANTHROPIC_API_KEY      # Tu clave de API
ANTHROPIC_BASE_URL     # Redirigir solicitudes a un proxy o pasarela
ANTHROPIC_MODEL        # Modelo predeterminado a usar

• ANTHROPIC_API_KEY: tu clave de API. Un punto crítico que aclara la documentación oficial: si configuras esta clave, se usará en lugar de tu suscripción activa (Pro / Max / Team / Enterprise). Para volver a usar tu suscripción, debes borrarla con unset ANTHROPIC_API_KEY. Nota: En el modo interactivo, Claude Code mostrará una confirmación para aprobar o rechazar el uso de esta clave, con la opción de recordarlo; en el modo no interactivo (-p), se usará directamente sin confirmación. Es común caer en este error: tener una suscripción Max activa pero ver que los cobros se realizan a través de la API por tener un export ANTHROPIC_API_KEY residual en ~/.zshrc (detalles en el artículo 04).

• ANTHROPIC_BASE_URL: redirige las solicitudes de API a tu proxy o pasarela. Esta es la variable clave para conectar modelos locales o usar intermediarios (protagonista en la configuración del artículo 05).

• ANTHROPIC_MODEL: especifica el modelo predeterminado. Ten en cuenta su prioridad: la opción --model y el comando /model dentro de la sesión tienen prioridad sobre esta variable (se detalla en la siguiente sección).

Grupo 2: Tiempos de espera (ajústalo si la conexión se cancela rápido)

Cuando la red es lenta o usas un proxy lejano, lo que más se ajusta son los tiempos de espera. Dos variables comunes:

Variable	Qué controla	Valor predeterminado
API_TIMEOUT_MS	Tiempo de espera de una solicitud de API	600000 (10 minutos)
BASH_DEFAULT_TIMEOUT_MS	Tiempo de espera por defecto para comandos bash de larga duración	120000 (2 minutos)

• API_TIMEOUT_MS: cuánto tiempo espera la solicitud de la API antes de expirar. Consejo oficial: auméntalo si la red es lenta o usas proxy. Pero ten cuidado: tiene un límite máximo de 2147483647; superar este valor causará un desbordamiento del temporizador interno y las solicitudes fallarán de inmediato (agregar un cero extra por error es común, lo que hace que todas las solicitudes fallen al instante).

• BASH_DEFAULT_TIMEOUT_MS: cuánto tiempo de ejecución da Claude por defecto a comandos largos (como instalar dependencias o compilar). Por defecto son 2 minutos; auméntalo si realizas compilaciones grandes.

Grupo 3: Privacidad y telemetría (para entornos estrictos o corporativos)

Mencionados en el artículo 21 sobre seguridad, controlan el envío de datos externos:

DISABLE_TELEMETRY=1      # Desactivar el reporte de telemetría
DO_NOT_TRACK=1           # Equivalente al anterior, convención común entre herramientas

• DISABLE_TELEMETRY: establécelo en 1 para desactivar la telemetría. El equipo oficial aclara que estos datos no incluyen tu código, rutas de archivos ni comandos bash; pero en entornos con requisitos estrictos de cumplimiento, configurarlo ofrece total tranquilidad.
• DO_NOT_TRACK: al establecerlo en 1, equivale a DISABLE_TELEMETRY. Es una convención común respetada por muchas herramientas de línea de comandos.

También existe un interruptor maestro: CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1, que equivale a configurar simultáneamente DISABLE_AUTOUPDATER, DISABLE_FEEDBACK_COMMAND, DISABLE_ERROR_REPORTING y DISABLE_TELEMETRY. Ideal para entornos completamente aislados.

Grupo 4: Cuentas múltiples y contexto (avanzado pero práctico)

Dos variables recomendadas:

• CLAUDE_CONFIG_DIR: cambia el directorio de configuración (por defecto ~/.claude). Todas las configuraciones, credenciales, historial de conversaciones y plugins se guardan allí. Su mayor utilidad es ejecutar múltiples cuentas en paralelo, como muestra el ejemplo oficial:

# Crear un directorio de configuración independiente para la cuenta de trabajo
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

Esto permite separar la cuenta personal de la del trabajo: ejecutas claude para el uso personal y claude-work para usar una configuración e inicio de sesión completamente aislados, manteniendo los historiales, credenciales y configuraciones de MCP separados sin interferencias.

• DISABLE_AUTO_COMPACT: configúralo en 1 para desactivar la compresión automática cuando el contexto se acerca al límite (mencionado en el artículo 19). El comando manual /compact seguirá funcionando. Úsalo solo si quieres decidir tú mismo cuándo comprimir; la mayoría de los usuarios pueden dejar el valor por defecto.

⚠️ Advertencia importante: La documentación oficial indica que Claude Code solo lee las variables de entorno al iniciar. Por lo tanto, si cambias alguna variable (ya sea en la shell o en settings.json), debes salir de claude y reiniciarlo para que se aplique el nuevo valor. Si el cambio no surte efecto, lo más probable es que falte reiniciar la sesión.

💡 Resumen rápido: Las variables más comunes se dividen en cuatro grupos: conexión y autenticación (ANTHROPIC_API_KEY/BASE_URL/MODEL), tiempos de espera (API_TIMEOUT_MS por defecto 10 min), privacidad (DISABLE_TELEMETRY/DO_NOT_TRACK) y cuentas múltiples (CLAUDE_CONFIG_DIR); cualquier cambio requiere reiniciar claude para aplicarse.

---

05 Prioridad: cuando se configura en varios lugares, quién manda

Al llegar a este punto surge una pregunta lógica: si configuro el modelo con la variable ANTHROPIC_MODEL, también lo elijo con /model en la conversación y además lo escribo en el campo model de settings.json, ¿cuál de todos se aplica?

Esto se define mediante la "prioridad de configuración (precedence)". Si no la entiendes, te enfrentarás al problema de "configuré esto pero no se está aplicando".

Recuerda la regla general oficial: las variables de entorno tienen prioridad sobre los campos de configuración:

Cuando el mismo comportamiento tiene tanto una variable de entorno como un campo de configuración, la variable de entorno tiene prioridad. Por ejemplo, ANTHROPIC_MODEL anula la configuración model. Si la variable de entorno no está configurada, se aplica el campo de configuración.

Analogía: la orden directa del director sobre el manual del empleado. El manual (los campos de settings.json) dice que "el límite de taxi es de 50"; pero el director te dice hoy en persona "este viaje es largo, repórtalo completo" (variable de entorno). En este viaje, por supuesto, obedeces la orden directa del director. La variable de entorno actúa como esa orden directa, superando los campos escritos en el manual. Si no hay orden directa (variable no configurada), regresas a lo establecido en el manual.

Sin embargo, hay una excepción importante que suele confundir a los principiantes: las variables de entorno no lo dominan todo. Para el caso del modelo, la documentación oficial aclara específicamente:

--model y /model anulan ANTHROPIC_MODEL.

Es decir, la prioridad para el modelo es la siguiente:

Comando /model / opción --model   ←  Prioridad máxima (tu decisión al instante)
        ↓ supera a
Variable ANTHROPIC_MODEL          ←  Prioridad media
        ↓ supera a
Campo model en settings.json      ←  Prioridad de respaldo

¿Por qué ocurre esto con el modelo? Es lógico: seleccionar el modelo con /model durante la sesión es una intención explícita al instante, por lo que debe superar a la variable que habías fijado previamente. Sigue la misma lógica de la orden directa: la instrucción más inmediata y explícita tiene la mayor prioridad.

Método de configuración	Prioridad relativa	En pocas palabras
Comando /model / opción --model	Máxima	Tu decisión explícita en la sesión o al iniciar
Variable ANTHROPIC_MODEL	Media	Tu valor predeterminado configurado
Campo model en settings.json	De respaldo	Se aplica si no se configuró ninguno de los anteriores

Nota: Esta regla de "comandos/opciones superando a variables de entorno" aplica específicamente a configuraciones como el modelo, y no a todas las funciones. Por ejemplo, CLAUDE_CODE_EFFORT_LEVEL sí sobrescribirá al comando /effort. Si tienes dudas sobre una variable específica, consulta su fila en la tabla de la documentación oficial en lugar de asumir su comportamiento.

Esto puede causar confusión: configuras un modelo en settings.json, pero en una sesión usas /model para cambiarlo temporalmente y lo olvidas, continuando la sesión con el modelo temporal y preguntándote por qué difiere de tu configuración. Recuerda: la decisión directa en la sesión /model tiene prioridad por diseño, no es un bug.

💡 Resumen rápido: La regla general es variable de entorno > campo de configuración; pero para el modelo hay una excepción: los comandos/opciones directos /model/--model superan a ANTHROPIC_MODEL. La regla es "lo más directo y específico tiene la mayor prioridad".

---

06 Práctica: configura una variable y verifica que funcione

La teoría sin práctica no sirve. Realizaremos un ejercicio básico: configurar una variable → iniciar la sesión → verificar su efectividad. No requiere configuraciones complejas previas y toma solo unos minutos.

Usaremos BASH_DEFAULT_TIMEOUT_MS (tiempo de espera por defecto de comandos bash). La elegimos porque es segura, fácil de observar y no afectará tu conexión si la configuras mal.

Paso 1: Observa el estado inicial (en la terminal, antes de iniciar claude)

Sin configurar nada, inicia una sesión directamente:

claude

Una vez dentro, hazle una pregunta simple sobre el tiempo de espera de bash:

¿Cuál es mi tiempo de espera predeterminado para comandos bash en milisegundos? Lee BASH_DEFAULT_TIMEOUT_MS en tu entorno; si no está configurada, indica el valor por defecto.

Resultado esperado: Te indicará que la variable no está configurada explícitamente y que usa el valor por defecto de 120000 (2 minutos). Anota este valor de referencia para comparar después. Sal de la sesión (escribe /exit o presiona Ctrl+C dos veces).

Paso 2: Configura un valor temporal en la shell e inicia la sesión

De regreso en la terminal, configura temporalmente un valor diferente (5 minutos) e inicia la sesión de inmediato:

export BASH_DEFAULT_TIMEOUT_MS="300000"
claude

En Windows PowerShell usa: $env:BASH_DEFAULT_TIMEOUT_MS = "300000" y luego claude.

Una vez dentro, haz la misma pregunta:

¿Cuál es mi tiempo de espera predeterminado para comandos bash en milisegundos?

Resultado esperado: Esta vez leerá 300000 (5 minutos) en lugar del valor por defecto de 120000. El cambio de 120000 a 300000 confirma que tu configuración temporal ha sido leída con éxito. Esto valida que el "Método 1: configuración temporal en shell" funciona.

Paso 3: Verifica que desaparece al cerrar la terminal

Sal de la sesión, cierra por completo esa ventana de la terminal, abre una nueva y ejecuta claude directamente (sin configurar la variable). Haz la misma pregunta.

Resultado esperado: Volverá a mostrar 120000 (el valor por defecto). Esto confirma que export solo afecta a la terminal donde se ejecutó, validando lo explicado en la sección 02.

Paso 4 (Opcional): Escríbela en settings.json para hacerla persistente

Si quieres que este valor se aplique siempre, independientemente de cómo inicies la sesión, escríbelo en settings.json. Lo más seguro es usar el archivo local que no se sube a git:

{
  "env": {
    "BASH_DEFAULT_TIMEOUT_MS": "300000"
  }
}

Escríbelo en .claude/settings.local.json (raíz del proyecto actual, no se sube a git) o en ~/.claude/settings.json (directorio principal, común a todos los proyectos), según el alcance que desees (ver tabla de la sección 03).

Guarda el archivo, abre una nueva terminal y ejecuta claude directamente (sin usar export). Haz la misma pregunta; ahora leerá de forma persistente 300000 y se aplicará en cada inicio futuro. Este es el beneficio de escribirlo en settings.json en comparación con la shell: lo configuras una vez y te olvidas.

Completar estos cuatro pasos te habrá permitido experimentar todo el flujo de las variables de entorno: configuración → validación → alcance → persistencia. A partir de ahora, configurar cualquier variable seguirá este mismo flujo.

💡 Resumen rápido: Para verificar si una variable funciona, lo más seguro es preguntar directamente a Claude qué valor está leyendo; experimenta primero con export temporal en la shell y luego muévela a settings.json para hacerla persistente.

---

07 Resumen

En este artículo hemos profundizado bajo la superficie para conocer y aprender a ajustar esa fila de interruptores generales que controlan los comportamientos básicos de Claude Code.

Repasemos los cinco puntos clave analizados:

Concepto	Respuesta	Detalle clave
Qué controlan	Conexión, autenticación, tiempos de espera y privacidad	Interruptores clave-valor leídos al iniciar para fijar comportamientos
Dónde configurarlas	Shell temporal / ~/.zshrc / env en settings.json	Elige según el alcance; para uso a largo plazo se recomienda settings.json
Qué archivo settings usar	Directorio principal / Raíz del proyecto (git) / .local (no git)	Las credenciales nunca deben subirse a git
Cuáles son las comunes	ANTHROPIC_*, API_TIMEOUT_MS, DISABLE_TELEMETRY, CLAUDE_CONFIG_DIR	Tienen valores por defecto; requiere reiniciar para aplicarse
Cómo se define la prioridad	Variable > Configuración; pero /model supera a ANTHROPIC_MODEL	Lo más directo y explícito tiene la mayor prioridad

Ahora eres capaz de: entender qué controlan las variables de entorno en Claude Code; decidir cuál de las tres formas de configuración usar según su alcance; saber qué archivos de settings.json se suben a git y cuáles no; identificar las variables más comunes de conexión, tiempos de espera, privacidad y cuentas múltiples; y resolver prioridades cuando configuras un parámetro en múltiples lugares. Y lo más importante: has configurado una variable, verificado que funcione y aprendido la diferencia entre la shell temporal y la persistencia en archivo.

Las variables de entorno no son para "usuarios avanzados", sino para configurarlas una vez y disfrutar de sus beneficios. Muchas de las configuraciones repetitivas que realizabas en las sesiones anteriores ahora se pueden automatizar con una sola variable.

---

El siguiente artículo es 43 "Flujo de trabajo con Git". Ahora que has configurado los comportamientos básicos de Claude Code, es hora de integrarlo en tu flujo de desarrollo diario. Y al hablar de desarrollo, es inevitable hablar de Git: dejar que Claude escriba mensajes de commit, analice diffs, cree PRs o resuelva conflictos... ¿Hasta dónde puede ayudarte con Git y qué aspectos debes supervisar tú mismo? Lo analizaremos en el próximo artículo. Considera esto: puedes dejar que la IA cree un git commit, pero al hacer un git push a producción, ¿te atreves a no supervisarlo?

---

Lecturas recomendadas

• Aplicación de escritorio (Desktop)
• Mejores prácticas: reuniendo buenos hábitos en un método de trabajo
• Ganchos (Hooks): activando disparadores en momentos específicos