Variables del proyecto

Cada sesión es una copia de trabajo recién creada: el .env de tu checkout principal no existe allí y no debe llegar por git. Las variables del proyecto son la respuesta de Chronos: un conjunto por workspace, guardado fuera del repositorio y entregado a todo lo que la sesión ejecuta, siempre.

Dónde viven

Los valores van al llavero del sistema (macOS Keychain, Windows Credential Manager). En la base de datos de Chronos solo quedan los nombres y sus flags: una copia de esa base nunca es una copia de tus secretos y nada se escribe en disco en claro.

Pertenecen al workspace, no a una sesión: sobreviven a cada sesión que abras, cierres, integres o descartes.

Definirlas

Abre el panel Run y pulsa el chip Variables. Si el proyecto ya tiene un .env ignorado por git, Chronos ofrece importarlo con un clic, sin teclear nada.

Dos formas de editar:

• Variables: una tabla con nombre, valor (enmascarado), si el agente puede leerla y borrar. El ojo revela un valor; esa acción queda auditada.
• Pegar .env: pega un .env entero. Entiende comentarios, prefijos export, comillas y valores multilínea (una clave PEM, un JSON de service account). Pegar fusiona sobre lo que ya hay.

Cómo llegan a tu código

Por dos vías, porque el ecosistema necesita ambas:

1. Entorno de proceso: inyectadas en los scripts verificados (setup, run, test, los gates de merge), en los servidores de desarrollo, en el terminal de la sesión y en el proceso del agente. Un comando se comporta igual lo lance quien lo lance.
2. Un fichero real: escrito en la copia de trabajo de cada sesión (.env por defecto). Next, Vite, Django o Rails leen el fichero, no el entorno del padre.

Las variables gestionadas por Chronos siempre ganan: una variable tuya nunca puede capturar el puerto de la sesión ni el alias de puerto de un target. Los nombres que secuestrarían un proceso (PATH, HOME, LD_*, DYLD_*) o que empiezan por CHRONOS_ se rechazan al guardar.

El fichero no puede acabar en un commit

Antes de escribirlo, Chronos comprueba las reglas de ignore del repositorio. Si el fichero no está ignorado, añade la entrada a .gitignore (creándolo si el repo no tiene). Ese cambio sí aparece en el diff y en el pull request, a propósito: un repositorio que no ignora su .env tiene un bug real y el arreglo queda donde debe, para todo el equipo, incluida la gente que nunca abre Chronos.

El fichero materializado nunca aparece en el diff. Y un .env que Chronos no generó no se sobrescribe ni se borra jamás.

Ocultar una variable al agente

Cada variable tiene un interruptor Agent. Apágalo y la variable sigue llegando a los scripts, a los servidores y al terminal (todo lo que lanza el propio daemon), pero queda fuera del entorno del agente y del fichero materializado, porque el agente puede leer la copia de trabajo.

Déjalo encendido en el caso normal

El agente ejecuta tus tests y tu build. Una variable que no ve es un comando que funciona desde el botón Run y falla cuando lo escribe el agente.

Cuándo aplican los cambios

Guardar reescribe el fichero de todas las sesiones abiertas al momento; el agente coge el entorno nuevo en su siguiente turno. Un servidor de desarrollo o un terminal ya en marcha conserva el entorno con el que arrancó (el entorno de un proceso no se puede cambiar desde fuera): reinícialo si necesitas ahí el valor nuevo.

Gobernanza

El pack workspace-env-vars es el interruptor de la empresa sobre esta función. Viene activado: son los secretos del propio desarrollador para su propio proyecto. Si tu organización lo apaga, la inyección y el fichero se detienen en todas partes a la vez y el editor pasa a solo lectura: ver Gobernanza. La auditoría registra nombres y cantidades, nunca valores.

Límites

• Un conjunto por workspace. En una sesión multi-repo se inyectan las variables del workspace principal.
• Linux aún no tiene backend de llavero; macOS y Windows sí.