Ir al contenido

El daemon

El daemon es tcc ejecutándose en segundo plano: un punto final HTTP en esta máquina y un servidor MCP para asistentes de IA. Con una cuenta propia también ejecuta un bucle de sincronización que mantiene la caché local al día.

Existe para máquinas sin sesión de escritorio — un servidor Linux, un agente de compilación, un contenedor. En macOS y Windows la app de escritorio ya ejecuta lo mismo mientras su ventana está abierta, así que ahí normalmente no arrancas el daemon a mano.

tcc daemon start
tcc daemon status
tcc daemon stop

start se ejecuta en primer plano y bloquea hasta que se detiene el proceso. Escribe un archivo PID, así que un segundo start se rechaza en lugar de pelear con el primero por el puerto, y un archivo PID obsoleto dejado por un fallo se limpia en el siguiente arranque.

stop le pide al daemon en marcha que se apague. status imprime si está en marcha, su id de proceso y su puerto — y dice claramente cuando encuentra un archivo PID de un proceso que ya no está vivo.

tcc daemon start se ejecuta de máquina a máquina por defecto. No tiene cuenta propia: responde en nombre de quien presente un token de la API de plataforma, no guarda caché local, y no ejecuta ningún bucle de sincronización. Los tokens del punto final local se rechazan en este modo, con un mensaje que lo dice.

Para darle al daemon una identidad propia en su lugar, inicia sesión primero con tcc setup y arráncalo con TCC_MODE=hybrid fijado. Entonces guarda una caché local, sincroniza en segundo plano, y acepta los tokens del punto final local descritos más abajo. Ese es el modo en el que siempre se ejecuta la app de escritorio, y el modo a elegir si quieres que el daemon se comporte como el propio cliente conectado de la máquina.

Un daemon híbrido en una cuenta que nunca ha ejecutado tcc setup arranca y sirve igualmente. No hace ninguna sincronización, porque no hay nada que sincronizar.

La sesión propia de un daemon dura como máximo 12 horas desde el inicio de sesión; después vuelve a iniciar sesión con tcc auth login --code (consulta Iniciar sesión). Los tokens de API de la plataforma no son sesiones y nunca terminan así, así que usa uno para todo lo que funcione sin supervisión.

Por defecto el daemon se ata a 127.0.0.1 — la dirección de loopback — en el puerto 19821. Nada fuera de esta máquina puede alcanzarlo. Eso es lo que hace seguro usar el punto final local sin contraseña desde herramientas que se ejecutan a su lado.

Dos variables de entorno cambian eso:

  • TCC_HTTP_PORT — un puerto distinto, cuando el 19821 está ocupado.
  • TCC_HTTP_BIND — una dirección de enlace distinta.

Cambiar la dirección de enlace es el único ajuste aquí con consecuencias reales. En el momento en que el daemon escucha en algo distinto de loopback queda alcanzable desde tu red, y la suposición en la que descansa el punto final local ya no se sostiene. Si lo haces, ponlo detrás de algo que autentique.

En Linux:

tcc daemon install-service

Esto escribe una unidad de usuario de systemd, la activa y la arranca, así que el daemon vuelve después de un reinicio. Se reinicia si falla. Compruébalo de la forma habitual:

systemctl --user status trusted-codes

El comando es solo para Linux. En macOS y Windows, usa en su lugar el propio arranque al iniciar sesión de la app de escritorio.

Los comandos encuentran el daemon por su cuenta

Sección titulada «Los comandos encuentran el daemon por su cuenta»

Cuando ya está en marcha un daemon o la app de escritorio, un comando tcc normal no duplica el trabajo — pasa la solicitud a la instancia en marcha e imprime la respuesta. Verás una línea que dice que se conectó. Cuando no hay nada en marcha, el mismo comando hace el trabajo él mismo.

No tienes que configurar esto, y el resultado es el mismo en ambos casos.

Un tcc en tu portátil puede hablar con un daemon que se ejecuta en otro sitio — una máquina compartida, un ejecutor de CI — en lugar de actuar como su propio cliente.

Para un solo comando:

tcc --server https://tcc.example.com --token <platform-api-token> code list

Para hacerlo el valor por defecto:

tcc config set-remote https://tcc.example.com --token <platform-api-token>
tcc config show-remote # la URL, con el token enmascarado
tcc config clear-remote # volver al daemon local

El ajuste se guarda bajo tu carpeta personal y se lee en cada invocación. Los indicadores --server y --token, y las variables de entorno TCC_REMOTE_URL y TCC_API_TOKEN, lo anulan para una sola ejecución.

Se necesita un token siempre que hay un servidor remoto fijado. Usa uno de tcc api-token generate, no uno de tcc config create-api-token. Cuando hay un remoto configurado, los comandos van ahí y a ningún otro sitio — si no se puede alcanzar el remoto, el comando falla en lugar de ejecutarse silenciosamente contra tu propia cuenta.

Las herramientas de esta máquina que hablan con la app de escritorio, o con un daemon arrancado en modo híbrido, usan un token que tú emites:

tcc config create-api-token --label claude --scope read
tcc config list-api-tokens
tcc config show-api-token claude
tcc config revoke-api-token claude

--scope es read, write o full, y por defecto es full. --ttl-hours le da al token una caducidad; omitirlo significa que no caduca, lo cual solo tiene sentido para un token que nunca sale de esta máquina. list-api-tokens enmascara los valores — show-api-token es el que imprime un token completo, así que mantenlo fuera de terminales compartidas y registros.

Estos son distintos de tcc api-token, que emite tokens para la propia plataforma Trusted Codes. Un daemon de máquina a máquina — el valor por defecto de tcc daemon start — rechaza los tokens locales y toma en su lugar un token de plataforma, y lo mismo hace un daemon remoto alcanzado con --server.

tcc también habla MCP, que es cómo un asistente de IA en tu máquina puede consultar un código o verificar palabras por ti. Esto no pasa por el daemon: configure escribe una entrada que le dice al asistente que arranque él mismo tcc mcp, y ese proceso habla directamente con tu cuenta. No necesitas un daemon en marcha para esto.

tcc mcp status # qué apps de IA están configuradas
tcc mcp configure cursor
tcc mcp remove cursor

Para Claude Code, usa claude mcp add como se muestra en Conectar un asistente. El configure claude-code actual escribe un archivo que Claude Code no lee.

configure admite claude-desktop, claude-code y cursor. El servidor MCP es una parte separada de tu plan respecto a la propia app de escritorio.