How to Configure .codeiumignore and Repository Exclusion Rules in Codeium

Enterprise engineering teams adopting AI code completion tools face a critical security requirement: ensuring proprietary algorithms, API keys, private certificates, and regulated test fixtures are never indexed or exposed to AI context retrieval, while preserving fluid autocomplete for the rest of the codebase. Codeium addresses this through a multi-tiered exclusion architecture spanning workspace-level .codeiumignore files, workstation-level global ignores, and enterprise administrative controls.

Understanding Codeium's Indexing Architecture

To understand how exclusion rules protect sensitive code, teams must understand how Codeium ingests source code:

1. Local Context Awareness: In developer IDEs (VS Code, JetBrains, or Windsurf / Devin Desktop), Codeium runs an indexing engine that analyzes codebases along semantic boundaries such as classes, functions, and interfaces. This engine parses repository structures into local representations to retrieve relevant code snippets during real-time typing and chat interactions.
2. Remote Multi-Repository Indexing: In enterprise deployments, Codeium can index repositories server-side to provide cross-repository context awareness across microservices and shared libraries.
3. Context Construction and Inference: When a developer requests a completion or asks an assistant question, Codeium gathers local cursor context, open tab context, and retrieved semantic snippets from its index. If a sensitive file is indexed, snippets from it could inadvertently be included in inference prompts.

Exclusion configurations prevent files from ever entering these indexing pipelines, eliminating the risk of accidental exposure at the root.

1. Project-Level Configuration: .codeiumignore

The primary mechanism for repository-level control is placing a .codeiumignore file in the root directory of your project workspace.

Placement and Compatibility

• File Location: Must reside at the repository root (<repo-root>/.codeiumignore).
• Syntax: Uses standard .gitignore glob pattern formatting.
• Compatibility Across Tool Evolutions: Codeium, Windsurf, and Devin Desktop environments recognize .codeiumignore. Related ignore files (.windsurfignore and .devinignore) share the same syntax, and tools inspect these files concurrently to determine exclusion boundaries.
• Default Behavior: Codeium automatically honors your repository's existing .gitignore patterns, hidden paths beginning with ., and node_modules. However, relying solely on .gitignore is insufficient when proprietary code or internal test fixtures are actively tracked in Git but must remain hidden from AI indexing.

Production .codeiumignore Configuration Template

Below is a battle-tested template that enterprise engineering teams can adopt and tailor for their repositories:

# ==============================================================================
# Security & Secret Management
# ==============================================================================
# Environment variable files and local overrides
.env
.env.*
!.env.example

# Cryptographic keys, certificates, and credentials
*.pem
*.key
*.pkcs12
*.pfx
*.cert
*.crt
id_rsa
id_ecdsa
id_ed25519
credentials.json
service-account*.json
secrets/
config/secrets.yml

# Cloud provider and token files
.aws/
.gcp/
.azure/
*token*
*.secret

# ==============================================================================
# Proprietary Core IP & Regulated Algorithms
# ==============================================================================
# Sensitive core intellectual property (e.g., proprietary trading logic, patented math)
src/core/proprietary_engine/
src/crypto/internal_ciphers/
internal/patented_algorithms/

# Note: Whitelist public interfaces if developers need autocomplete against signatures
# !src/core/proprietary_engine/public_interfaces.ts

# ==============================================================================
# Regulated Data, PII, and Heavy Test Fixtures
# ==============================================================================
# Large test dumps, production-like mocks, and synthetic database snapshots
tests/fixtures/prod_dumps/
tests/data/sanitized_pii/
*.sqlite
*.sqlite3
*.db
*.dump
*.parquet
*.csv.gz

# ==============================================================================
# Build Artifacts, Generated Schemas, and Third-Party Blobs
# ==============================================================================
# Compiled code and third-party dependencies (saves indexing memory and CPU)
dist/
build/
out/
target/
vendor/
node_modules/
*.min.js
*.min.css
*.wasm

Key Syntax Rules and Pattern Precedence

• Directory Matching: Always append a trailing slash (e.g., secrets/) to restrict exclusion to directories and avoid unintentional matching of similarly named source files.
• Recursive Globbing: Use **/ to match paths across nested subdirectories (e.g., **/internal_keys/*.json).
• Leading Slash: Use a leading slash / to anchor patterns to the repository root (e.g., /config/local.json ignores only the root file, not packages/app/config/local.json).
• Negation Exceptions (!): An exclamation mark un-ignores a specific path. However, note that if a parent directory is excluded (e.g., secrets/), subfiles cannot be re-included with !secrets/public.json unless the directory itself is traversed. Furthermore, .codeiumignore exceptions do not override patterns strictly defined in .gitignore.

2. Workstation-Level Configuration: Global Ignore Files

Engineering teams often require a baseline safeguard on developer machines so that even if a developer clones a repository that lacks a committed .codeiumignore, sensitive patterns remain shielded locally.

Global File Path

Place a global .codeiumignore file in the user's home configuration directory:

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

Behavior

• The global ignore file applies to all workspaces opened on that workstation.
• It operates alongside repository-level ignore files; rules are combined so that a path matched by either the global or repository ignore is excluded.
• Organizations can distribute and standardize this file across developer machines via dotfile repositories or configuration management frameworks (Ansible, Chef, MDM).

3. Team and Enterprise Repository Exclusion Controls

While file-level ignore rules handle fine-grained paths, enterprise organizations must govern repository access at the infrastructure level. In enterprise environments (managed via the Codeium Admin Console or Cognition Devin Enterprise Settings), administrators enforce repository-wide indexing and access boundaries.

Enterprise Repository Allowlisting

For organizations utilizing Codeium Remote Indexing across centralized code hosting platforms (GitHub Enterprise Server, GitHub Enterprise Cloud, GitLab Self-Managed, Bitbucket Data Center, or Azure DevOps):

1. Connector Scoping: When setting up source code management (SCM) connectors in the admin dashboard, administrators select which repositories are synchronized. Repositories not explicitly added to the allowlist are omitted from remote indexing entirely.
2. Default-Deny Architecture: New repositories created in the SCM provider should remain excluded until administrators explicitly onboard them.
3. Branch-Level Scoping: Remote indexing can be restricted to designated production or mainline branches (e.g., main or release/*), preventing indexing of unvetted feature branches or experimental spikes.

Identity and Role-Based Access Control (RBAC)

Enterprise context retrieval respects organizational permission boundaries:

• IdP Group Synchronization: By integrating with identity providers (Okta, Microsoft Entra ID, Ping Identity) via SAML 2.0 or OIDC, Codeium maps code context access to user group memberships.
• Context Partitioning: If a developer does not possess read access to a specific private repository within the organization's Git host, the remote indexing engine blocks that repository's context from being retrieved or populated into their IDE suggestions.

Administrative Terminal and File Permissions

In managed enterprise deployments, administrators can enforce strict, tamper-proof client permission rules that take precedence over developer local settings:

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

These rules prevent local AI agents from accessing, reading, or modifying sensitive files on developer filesystems regardless of what prompt is submitted.

Comparison of Exclusion Layers

Enterprise defense-in-depth requires combining multiple layers of protection:

Verification and Operational Troubleshooting

After creating or updating ignore configurations, teams should verify that sensitive paths are excluded:

1. Monitor Workspace File Limits and Memory Allocation

• Codeium's local indexing engine enforces an indexing file limit (typically up to 10,000 files for machines with ~10 GB RAM).
• Files matched by .codeiumignore do not count toward the workspace indexing limit and do not consume indexing memory (~300 MB per 5,000 indexed files).
• If your indexed file count drops after adding ignore rules, the paths have been excluded.

2. Verify Suggestion and Chat Boundaries

• Open an excluded file (such as a proprietary algorithm implementation).
• Attempt code completion on internal symbols or query the chat assistant regarding proprietary functions defined exclusively in that file.
• The assistant should state that it has no context or refuse to auto-complete the internal implementation, confirming that the index has quarantined the file.

3. Check Conflicting Settings

• Gitignore Access Setting: In certain IDE releases, an administrative or user toggle governs whether the AI agent can read files ignored by Git. Ensure this setting aligns with company policy.
• Direct File Mentions: Even if a file is excluded from passive indexing, using explicit @filename syntax in chat can trigger a direct file read if the file is open and user permissions allow it. Enforce administrative client file deny rules if direct reads must be prohibited.
• Index Cache Refresh: If a path was previously indexed before .codeiumignore was added, reload the IDE workspace or trigger an index rebuild from settings to clear legacy cached embeddings.

Enterprise Defense-in-Depth Best Practices

Configuring ignore files is an essential operational boundary, but security teams should treat it as one part of a comprehensive strategy:

1. Keep Secrets Out of Source Code: Never store plaintext credentials or private keys in the repository. Use centralized secrets managers (HashiCorp Vault, AWS Secrets Manager, Doppler, 1Password Developer Tools) and inject credentials via environment variables at runtime.
2. Automate Pre-Commit Scanning: Deploy automated scanners (such as Gitleaks or TruffleHog) in pre-commit hooks and CI/CD pipelines to block credentials from being committed to Git.
3. Commit .codeiumignore to Version Control: Keep .codeiumignore tracked in the repository root so all team members automatically inherit the exclusion rules upon checkout.
4. Deploy Zero Data Retention (ZDR) and Hybrid Architectures: For organizations with stringent compliance standards, adopt Enterprise deployments that guarantee zero data retention on prompts and completions, or utilize Hybrid VPC deployments where vector indices and code stay within company-managed boundaries.

References

• 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