Cómo configurar .codeiumignore y las reglas de exclusión de repositorios en Codeium

Los equipos de ingeniería que implementan asistentes de código basados en inteligencia artificial enfrentan un desafío crítico de gobernanza: garantizar que las claves privadas, los algoritmos propietarios y los conjuntos de datos de prueba regulados no sean indexados ni transferidos a la nube, manteniendo al mismo tiempo un autocompletado ágil en el resto del proyecto. Codeium resuelve este desafío mediante un modelo de exclusión en capas que abarca archivos .codeiumignore en la raíz del repositorio, exclusiones globales en la máquina del desarrollador y políticas centralizadas en la consola de administración empresarial.

Arquitectura de indexación de Codeium y riesgos de seguridad

Para definir exclusiones efectivas, es esencial comprender cómo procesa el código fuente el motor de Codeium:

1. Reconocimiento de contexto local (Local Context Awareness): Dentro del entorno de desarrollo (VS Code, JetBrains, Windsurf o Devin Desktop), el indexador local analiza el proyecto dividiendo los archivos según límites semánticos (clases, funciones e interfaces). Con esto genera representaciones vectoriales locales que sirven para recuperar fragmentos relevantes en tiempo real.
2. Indexación remota multirrepositorio: En implementaciones empresariales (Codeium Enterprise), el sistema indexa proyectos de forma centralizada en el servidor para facilitar contexto cruzado entre microservicios y bibliotecas compartidas.
3. Puntos de riesgo: Si un archivo sensible no se excluye, claves de API en archivos .env, certificados criptográficos (.pem), módulos matemáticos patentados o datos de prueba con información personal identificable (PII) pueden ser fragmentados e incorporados al índice. Si el recuperador semántico los selecciona, estos fragmentos se enviarán al modelo de lenguaje en el prompt de inferencia.

Las reglas de exclusión aíslan estas rutas antes de que entren en el flujo de indexación, mitigando el riesgo desde el origen.

1. Configuración a nivel de proyecto: .codeiumignore

El mecanismo principal para delimitar el contexto dentro de un proyecto consiste en ubicar un archivo .codeiumignore en la raíz del repositorio.

Ubicación y compatibilidad

• Ruta de archivo: Debe encontrarse en el directorio raíz del espacio de trabajo (<repo-root>/.codeiumignore).
• Sintaxis: Sigue el estándar de patrones glob de .gitignore.
• Compatibilidad entre herramientas: Codeium, Windsurf y Devin Desktop reconocen de forma nativa la sintaxis de .codeiumignore. Archivos homólogos como .windsurfignore y .devinignore emplean la misma convención y son evaluados de manera conjunta.
• Comportamiento predeterminado: Codeium respeta por defecto el archivo .gitignore del proyecto, las rutas ocultas que comienzan con punto . y el directorio node_modules. No obstante, cuando un equipo necesita versionar en Git código confidencial (como suites de pruebas complejas o arquitecturas internas) pero desea ocultarlo del motor de IA, .codeiumignore es la herramienta idónea.

Plantilla de producción de .codeiumignore

A continuación se presenta una plantilla estructurada y lista para entornos empresariales:

# ==============================================================================
# Secretos, certificados y variables de entorno
# ==============================================================================
# Archivos de entorno local
.env
.env.*
!.env.example

# Claves privadas, certificados y credenciales
*.pem
*.key
*.pkcs12
*.pfx
*.cert
*.crt
id_rsa
id_ecdsa
id_ed25519
credentials.json
service-account*.json
secrets/
config/secrets.yml

# Tokens y configuraciones de proveedores de nube
.aws/
.gcp/
.azure/
*token*
*.secret

# ==============================================================================
# Propiedad intelectual y algoritmos propietarios
# ==============================================================================
# Motores de cálculo patentados y lógica interna confidencial
src/core/proprietary_engine/
src/crypto/internal_ciphers/
internal/patented_algorithms/

# Nota: Descomentar si se requiere autocompletado en interfaces públicas
# !src/core/proprietary_engine/public_interfaces.ts

# ==============================================================================
# Datos regulados, información personal y fixtures de prueba
# ==============================================================================
# Volcados de bases de datos y muestras de prueba masivas
tests/fixtures/prod_dumps/
tests/data/sanitized_pii/
*.sqlite
*.sqlite3
*.db
*.dump
*.parquet
*.csv.gz

# ==============================================================================
# Artefactos de compilación y dependencias externas
# ==============================================================================
dist/
build/
out/
target/
vendor/
node_modules/
*.min.js
*.min.css
*.wasm

Reglas esenciales de sintaxis

• Barra diagonal final en directorios: Siempre añade una barra al final (secrets/) para indicar que se trata de una carpeta y evitar coincidencias accidentales con archivos de código del mismo nombre.
• Comodín recursivo: Emplea **/ para abarcar subdirectorios anidados a cualquier profundidad (por ejemplo, **/internal_keys/*.json).
• Anclaje a la raíz: Utiliza una barra inicial / para limitar el patrón exclusivamente al nivel superior del repositorio (por ejemplo, /config/local.json no afectará a packages/subapp/config/local.json).
• Reglas de inclusión (!): El signo de exclamación permite incluir excepciones a una regla general. Sin embargo, si un directorio padre fue excluido en su totalidad (secrets/), no es posible reincorporar un archivo hijo (!secrets/public.json) a menos que el directorio raíz permita el recorrido. Además, las excepciones en .codeiumignore no siempre anulan reglas estrictas de .gitignore.

2. Configuración a nivel de estación de trabajo: archivo global

Para prevenir brechas en proyectos recién clonados que aún no posean un archivo .codeiumignore confirmado en Git, los equipos pueden desplegar una regla global en cada estación de trabajo.

Rutas del archivo global

El archivo debe ubicarse en el directorio principal del usuario:

• macOS / Linux: ~/.codeium/.codeiumignore
• Windows: %USERPROFILE%\.codeium\.codeiumignore

Funcionamiento

• Se aplica de forma automática a todos los proyectos y espacios de trabajo abiertos en la máquina.
• Opera en combinación con los archivos .codeiumignore y .gitignore locales; si una ruta coincide con cualquiera de ellos, queda descartada.
• Los equipos de infraestructura y seguridad pueden distribuir este archivo mediante repositorios de dotfiles corporativos, scripts de aprovisionamiento o herramientas MDM.

3. Gobernanza empresarial y exclusión de repositorios en el servidor

Las reglas en archivos locales son editables por los desarrolladores y no bastan para una auditoría rigurosa. En planes empresariales (Codeium Enterprise o Cognition Devin Enterprise), la administración se realiza desde la consola central.

Lista blanca de repositorios (Conectores SCM)

Al integrar sistemas de control de versiones corporativos (GitHub Enterprise, GitLab Self-Managed, Bitbucket Data Center o Azure DevOps):

1. Inclusión explícita de repositorios: Los administradores seleccionan únicamente los repositorios autorizados para indexación. Todo repositorio no marcado queda completamente fuera del motor de indexación remota.
2. Delimitación de ramas: Es posible restringir la indexación a ramas estables o de producción (main, release/*), impidiendo que ramas de desarrollo con credenciales temporales sean procesadas.

Control de acceso basado en roles (RBAC) y sincronización con IdP

El motor de recuperación respeta estrictamente los privilegios individuales de los usuarios:

• Sincronización de grupos de identidad: Mediante SAML 2.0 u OIDC con proveedores como Okta o Microsoft Entra ID, Codeium replica las estructuras de permisos organizacionales.
• Aislamiento de contexto: Si un desarrollador no tiene permisos de lectura sobre un repositorio en la plataforma Git corporativa, el indexador jamás incluirá fragmentos de ese repositorio en sus sugerencias de código.

Políticas de permisos forzadas en el cliente

Los administradores pueden distribuir políticas de permisos inmutables que prevalecen sobre cualquier configuración local:

{
  "deny": [
    "Read(~/sensitive-data/**)",
    "Read(/etc/security/**)",
    "Write(.env*)"
  ],
  "ask": [
    "Exec(git push*)"
  ],
  "allow": [
    "Read(~/workspace/standard-repo/**)"
  ]
}

La directiva deny bloquea cualquier intento de lectura o modificación de archivos confidenciales por parte del agente local.

Comparativa de niveles de exclusión

La defensa en profundidad se estructura a través de diferentes niveles de control:

Procedimiento de verificación y resolución de problemas

Una vez configuradas las reglas, se debe corroborar que los archivos sensibles hayan sido desindexados satisfactoriamente:

1. Comprobación del límite de archivos y consumo de memoria

• El motor local impone un umbral máximo de archivos a indexar (habitualmente hasta 10.000 archivos en equipos con 10 GB de RAM).
• Los archivos ignorados mediante .codeiumignore no computan en este límite ni consumen memoria RAM (alrededor de 300 MB por cada 5.000 archivos).
• Si el contador de archivos del índice disminuye tras aplicar las reglas, la exclusión ha tomado efecto.

2. Pruebas de aislamiento en el editor y en el chat

• Abre un archivo confidencial dentro del directorio excluido.
• Intenta autocompletar una función exclusiva de dicho archivo en un módulo externo o consulta al asistente de chat sobre su lógica interna.
• El asistente debe responder que carece de contexto o abstenerse de autocompletar la función interna, confirmando que el índice ha aislado el archivo.

3. Aspectos a tener en cuenta

• Parámetro de acceso a Gitignore: Revisa en las preferencias del editor la opción relativa al acceso del agente a archivos ignorados por Git (Gitignore access). Para evitar ambigüedades, incluye siempre las rutas críticas en .codeiumignore.
• Menciones explícitas con @archivo: Excluir un archivo de la indexación pasiva no impide que, al citarlo expresamente con @nombre_archivo en el chat, el agente intente leerlo del disco si los permisos del sistema lo admiten. Para impedirlo por completo, utiliza reglas administrativas de tipo deny.
• Reconstrucción del índice en caché: Si los archivos fueron indexados antes de crear .codeiumignore, reinicia el espacio de trabajo o ejecuta una reconstrucción de índice (Re-index) desde los ajustes del editor para purgar representaciones vectoriales antiguas.

Buenas prácticas para la seguridad del código con IA

La configuración de exclusiones es fundamental, pero debe complementarse con una estrategia integral:

1. Evitar almacenar secretos en el código: Centraliza credenciales en gestores dedicados (HashiCorp Vault, AWS Secrets Manager, Doppler) e inyéctalas en tiempo de ejecución.
2. Escaneo automatizado previo al commit: Emplea utilidades como Gitleaks o TruffleHog en hooks de pre-commit y flujos de integración continua para rechazar credenciales antes de que ingresen al historial.
3. Controlar .codeiumignore en Git: Registra .codeiumignore en el repositorio para que todo el equipo comparta los mismos límites de seguridad de manera uniforme.
4. Implementar acuerdos de retención cero (ZDR) o entornos híbridos: En sectores regulados, opta por planes Enterprise con garantía de no retención de datos o arquitecturas híbridas donde los índices y el código permanezcan en la infraestructura privada de la empresa.

Referencias

• Index a Repository - Devin Docs
• Local Agent Controls - Devin Docs
• Devin CLI Team Settings - Devin Docs
• Devin Desktop admin controls reference - Devin Docs
• Security at Cognition - Devin Docs