How Software Developers Configure Supermaven Repository Context Settings and Ignore Files to Manage Codebase Indexing and Privacy

Modern AI-assisted software engineering relies heavily on deep contextual awareness. While early code completion engines operated purely on local token heuristics or short prefix-suffix snippets, state-of-the-art tools leverage expansive context windows to analyze architectural patterns, custom libraries, project dependencies, and multi-file relationships across entire repositories. Supermaven established itself as an industry benchmark in this space by combining an ultra-large 1-million-token context window with sub-200-millisecond completion latency powered by its custom neural architecture. However, providing an AI agent with comprehensive visibility into a codebase introduces critical security and compliance challenges: proprietary intellectual property, production configuration secrets, private cryptographic keys, and sensitive customer data must not be inadvertently ingested, transmitted, or cached.

Configuring Supermaven to balance rich codebase intelligence with rigorous data privacy requires understanding its context indexing mechanisms, its data governance policies, and the configuration levers available across different integrated development environments (IDEs). Because Supermaven does not implement a universal root-level ignore file like standard version control systems, developers must employ a layered configuration strategy—combining editor-level exclusion rules, conditional plugin initialization, workspace scoping, and modern repository hygiene—to control exactly what code is indexed and transmitted.

The Architectural Mechanics of Supermaven Repository Context

To manage repository context effectively, engineering teams must first understand how Supermaven builds its mental model of a project and where data boundaries exist between local hardware and cloud inference endpoints.

┌──────────────────────────────────────────────────────────────────────────┐
│                   Supermaven Context & Privacy Architecture              │
├──────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  Local Developer Environment                                             │
│  ┌────────────────────────────────────────────────────────────────────┐  │
│  │ Active Workspace / Repository                                      │  │
│  │  ├── Source Files (*.ts, *.py, *.go) ──> [Local File Watcher]      │  │
│  │  ├── Sensitive Files (.env, *.key)   ──> [Exclusion Filters]       │  │
│  │  └── Open Editor Buffers             ──> [Buffer State Sync]       │  │
│  └───────────────────────────────────┬────────────────────────────────┘  │
│                                      │ Filtered Context Payload          │
│                                      ▼ (HTTPS / TLS 1.3)                 │
│  Supermaven Cloud Infrastructure (AWS)                                   │
│  ┌────────────────────────────────────────────────────────────────────┐  │
│  │ 1-Million-Token Context Aggregator                                 │  │
│  │  ├── Long-Range Sequence Modeling (Babble Engine)                  │  │
│  │  ├── Fast Multi-File Semantic Grounding                            │  │
│  │  └── Sub-200ms Next-Token Completion Generation                    │  │
│  └───────────────────────────────────┬────────────────────────────────┘  │
│                                      │                                   │
│  Privacy & Retention Guardrails      │                                   │
│  ┌───────────────────────────────────┴────────────────────────────────┐  │
│  │ • 7-Day Absolute Data Retention (Automatic Ephemeral Purge)        │  │
│  │ • Strict Zero-Training Guarantee (Code Data Never Used for Weights)│  │
│  │ • Isolation from Third-Party Model Providers (Inline Engine Only)  │  │
│  └────────────────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────────────┘

Context Aggregation and the 1M Token Window

Unlike traditional Language Server Protocol (LSP) integrations that compute abstract syntax trees (ASTs) on the developer's local CPU, Supermaven utilizes a cloud-native indexing pipeline:

1. Local File Ingestion: Upon opening a project folder, the Supermaven extension registers file-system watchers to discover project assets, evaluate repository structure, and track open buffers.
2. Streaming Context Assembly: As developers navigate and modify files, the client synchronizes cursor position, recent edit history, and related project modules into an aggregated context payload.
3. Cloud-Based Long-Context Inference: The aggregated context is streamed to Supermaven's high-performance inference servers hosted on Amazon Web Services (AWS). Here, the model processes up to 1,000,000 tokens of codebase context to surface inline completions that accurately reflect cross-module interfaces, custom type definitions, and framework idiomatic usage.
4. Sub-200ms Delivery: By avoiding on-device neural evaluation, Supermaven minimizes battery drain and fan noise on developer laptops while achieving near-instantaneous completion speeds.

The operational challenge arises because the client file watcher and buffer synchronizer will, by default, scan all accessible files within the workspace root unless developers deliberately configure boundaries.

Supermaven Privacy Framework: Understanding the Code Policy

Before modifying IDE configuration files, developers and security officers must understand the legal and technical protections established by the Supermaven Code Policy and Privacy Policy.

┌──────────────────────────────────────────────────────────────────────────────────┐
│                   Supermaven Data Classification & Handling                      │
├────────────────────────────┬─────────────────────────────────────────────────────┤
│ Data Category              │ Technical Treatment & Retention Policy              │
├────────────────────────────┼─────────────────────────────────────────────────────┤
│ Code Data                  │ • Source code uploaded via official editor plugins. │
│                            │ • Subject to a strict 7-day retention limit.        │
│                            │ • Automatically purged from internal AWS systems.   │
│                            │ • NEVER used to train or refine commercial models.  │
│                            │ • Never shared with unauthorized third parties.     │
├────────────────────────────┼─────────────────────────────────────────────────────┤
│ Supermaven Chat Data       │ • Prompts and code explicitly submitted into chat.  │
│                            │ • Transmitted to selected third-party providers     │
│                            │   (e.g., Anthropic, OpenAI) depending on model.     │
│                            │ • Governed by third-party provider terms.           │
├────────────────────────────┼─────────────────────────────────────────────────────┤
│ Account & Telemetry Data   │ • User emails, IP addresses, billing identifiers.   │
│                            │ • Handled under standard Privacy Policy guidelines. │
│                            │ • Stored independently of source code repositories. │
└────────────────────────────┴─────────────────────────────────────────────────────┘

The 7-Day Ephemeral Retention Rule

Supermaven explicitly differentiates between user account metadata and proprietary source code:

• Strict Deletion Schedule: Any Code Data uploaded to Supermaven servers during inline autocomplete sessions is held for a maximum of 7 days before being completely purged from internal storage systems.
• No Model Training: Supermaven contractual terms guarantee that Code Data is never used to develop, fine-tune, or evaluate machine learning models. Your proprietary algorithms and business logic do not leak into future foundation models.
• Infrastructure Security: Code Data is processed within isolated VPC instances on AWS. Third-party infrastructure access is restricted to essential infrastructure hosting providers under strict confidentiality agreements.

Inline Completion vs. Interactive Chat

A critical distinction exists between inline code completion and Supermaven Chat:

• Inline Completions: Rely exclusively on Supermaven's internal neural infrastructure. Code snippets transmitted to produce inline suggestions remain covered under the strict zero-training and 7-day retention rules.
• Interactive Chat: When developers invoke chat capabilities and configure models such as Claude 3.5 Sonnet or GPT-4o, the relevant code excerpts and prompts are routed to external model vendors (Anthropic or OpenAI). Those transmissions fall under the respective third-party vendor's data handling policies rather than Supermaven's internal infrastructure protections.

Configuring Ignore Files and Repository Scope in Neovim

Neovim developers frequently adopt Supermaven via the official supermaven-nvim plugin due to its minimal footprint and rapid response times. However, configuring file exclusion in Neovim requires careful attention to the plugin's configuration schema.

Neovim Buffer Lifecycle with Supermaven:

  [File Opened in Buffer]
           │
           ▼
  [Check `condition()`] ──── Returns false ───> [Supermaven Halted / No Network Traffic]
           │
      Returns true
           │
           ▼
  [Check `ignore_filetypes`] ── Matches ignore ──> [Suggestions Hidden / UI Suppressed]
           │                                            │
      Not ignored                                       ▼
           │                                 *Notice: Buffer may still sync*
           ▼
  [Active Inline Completions]

1. Basic Filetype Suppression with ignore_filetypes

The simplest configuration option in supermaven-nvim is the ignore_filetypes table. This setting instructs the plugin not to display completion suggestions when editing specific file formats:

-- ~/.config/nvim/lua/plugins/supermaven.lua (or init.lua)
require("supermaven-nvim").setup({
  keymaps = {
    accept_suggestion = "<Tab>",
    clear_suggestion = "<C-]>",
    accept_word = "<C-j>",
  },
  ignore_filetypes = {
    env = true,          -- Suppress suggestions in .env files
    markdown = true,     -- Suppress in documentation/notes
    text = true,         -- Plain text files
    yaml = true,         -- Prevent autocomplete on Kubernetes/CI configs
    json = true,         -- Configuration schemas and package manifests
    sql = true,          -- Database queries and migrations
    gitcommit = true,    -- Git commit messages
  },
  color = {
    suggestion_color = "#888888",
    cterm = 244,
  },
  disable_inline_completion = false,
  disable_keymaps = false,
})

2. The Buffer Transmission Caveat and Advanced condition() Guardrails

A critical technical nuance identified by security-conscious developers is that ignore_filetypes primarily suppresses the rendering of inline suggestions in the editor UI. In certain versions of the language server client, file buffers loaded into memory may still be captured by the background daemon.

To guarantee that confidential files and sensitive directories are completely shielded from the Supermaven process, developers should utilize the condition() callback. The condition() function evaluates dynamically before Supermaven engages with a buffer:

require("supermaven-nvim").setup({
  -- Dynamic gatekeeper: return false to completely stop Supermaven on the buffer
  condition = function()
    local filepath = vim.api.nvim_buf_get_name(0)
    
    -- Exclude files with no path (temporary scratch buffers)
    if filepath == "" then
      return true
    end

    -- 1. Exclude sensitive environment files and secrets
    if string.match(filepath, "%.env") 
       or string.match(filepath, "credentials")
       or string.match(filepath, "secrets/")
       or string.match(filepath, "/%.aws/")
       or string.match(filepath, "/%.ssh/") then
      return false
    end

    -- 2. Exclude cryptographic certificates and keys
    if string.match(filepath, "%.pem$")
       or string.match(filepath, "%.key$")
       or string.match(filepath, "%.crt$") then
      return false
    end

    -- 3. Exclude specific proprietary projects or compliance-restricted directories
    if string.match(filepath, "/work/proprietary%-fintech/")
       or string.match(filepath, "/client%-classified/") then
      return false
    end

    -- 4. Exclude oversized data payloads or compiled assets
    local file_size = vim.fn.getfsize(filepath)
    if file_size > 1048576 then -- 1 MB limit
      return false
    end

    return true
  end,
})

3. Programmatic Control via Autocommands

For air-gapped security when opening private keys or compliance-restricted repositories, developers can invoke Supermaven's programmatic API directly in Neovim autocommands:

-- Force-stop Supermaven on sensitive buffer events
vim.api.nvim_create_autocmd({ "BufRead", "BufNewFile" }, {
  pattern = { "*.env", "*.env.*", "*/secrets/*", "*.pem", "*.key" },
  callback = function()
    pcall(function()
      require("supermaven-nvim.api").stop()
    end)
  end,
})

-- Re-enable Supermaven when entering approved source files
vim.api.nvim_create_autocmd({ "BufEnter" }, {
  pattern = { "*.ts", "*.tsx", "*.js", "*.py", "*.go", "*.rs", "*.cpp" },
  callback = function()
    local filepath = vim.api.nvim_buf_get_name(0)
    if not string.match(filepath, "%.env") and not string.match(filepath, "secrets/") then
      pcall(function()
        require("supermaven-nvim.api").start()
      end)
    end
  end,
})

Configuring Indexing Boundaries in Visual Studio Code

In Visual Studio Code, Supermaven operates as an extension communicating through the language server protocol. Because Supermaven does not read a specialized .supermavenignore file from the workspace root, developers manage indexing scope through VS Code's native file exclusion rules, workspace settings, and .gitignore.

┌───────────────────────────────────────────────────────────────────────────┐
│                    VS Code Context Exclusion Hierarchy                    │
├───────────────────────────────────────────────────────────────────────────┤
│                                                                           │
│   User Settings (Global ~/.config/Code/User/settings.json)                │
│     └── Excludes personal keys, SSH directories, and global credentials   │
│                                                                           │
│   Workspace Settings (.vscode/settings.json)                              │
│     └── Excludes project secrets, environment files, and build artifacts  │
│                                                                           │
│   Project .gitignore                                                      │
│     └── Standard repository hygiene; respected by indexing tools          │
│                                                                           │
│   Extension Enablement Scope                                              │
│     └── Disable Supermaven entirely for sensitive client workspaces       │
│                                                                           │
└───────────────────────────────────────────────────────────────────────────┘

1. Workspace Configuration (.vscode/settings.json)

To prevent Supermaven and related indexing tools from parsing sensitive configuration files, add explicit exclusion patterns to your project's .vscode/settings.json:

{
  "files.exclude": {
    "**/.git": true,
    "**/.svn": true,
    "**/.hg": true,
    "**/CVS": true,
    "**/.DS_Store": true,
    "**/Thumbs.db": true,
    "**/.env*": true,
    "**/secrets/**": true,
    "**/*.pem": true,
    "**/*.key": true,
    "**/*.p12": true,
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true,
    "**/coverage": true
  },
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true,
    "**/.env*": true,
    "**/secrets/**": true
  },
  "files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/.git/subtree-cache/**": true,
    "**/node_modules/*/**": true,
    "**/.env*": true,
    "**/secrets/**": true
  }
}

Why files.watcherExclude Matters

The files.watcherExclude directive is particularly important for AI coding assistants. When files are omitted from the editor's file watcher, the extension's background indexing process does not receive file-system event notifications when those files are modified, preventing accidental sync loops of confidential tokens.

2. Workspace-Level Extension Toggling

When contracting across multiple organizations or switching between open-source projects and proprietary enterprise codebases, blanket settings are often insufficient. Developers should toggle Supermaven on a per-workspace basis:

1. Open the confidential project in VS Code.
2. Open the Command Palette (Ctrl+Shift+P on Linux/Windows, Cmd+Shift+P on macOS).
3. Type and select Extensions: Disable (Workspace).
4. Search for Supermaven and press Enter.

This ensures the language client binary is completely terminated within that workspace instance, preventing any background indexing, network traffic, or telemetry transmission.

Developer Workspace Segmentation:

[Standard Open Source Project] ──> Supermaven Enabled (1M Context Active)
[Internal Tooling Repository]  ──> Supermaven Enabled (Exclusions via settings.json)
[Proprietary Fintech Monorepo] ──> Supermaven Disabled at Workspace Level (Air-Gapped)

JetBrains IDE Configuration

Developers using IntelliJ IDEA, WebStorm, PyCharm, or other JetBrains IDEs interact with Supermaven through the JetBrains Marketplace plugin. JetBrains provides built-in mechanisms to constrain code inspection and AI indexing.

1. Scopes and Excluded Folders

1. Right-click any directory containing sensitive data (e.g., config/secrets, infra/credentials).
2. Select Mark Directory as -> Excluded.
3. Excluded directories are omitted from code inspection, symbol indexing, and completion pipelines.

2. File Type Ignorance

To prevent JetBrains and third-party completion extensions from scanning configuration files:

1. Navigate to Settings / Preferences -> Editor -> File Types.
2. Locate Ignored Files and Folders.
3. Append sensitive patterns:

   *.env;*.pem;*.key;*.p12;secrets;credentials;
   

4. Click Apply.

The Migration to Cursor and Native .cursorignore

In November 2024, the Supermaven team joined Cursor, and the underlying long-context technology (including the custom inference architecture and multi-file sequence modeling) was integrated into Cursor's native autocomplete engine ("Cursor Tab"). For software developers transitioning from standalone Supermaven to the Cursor editor, repository context and privacy management become significantly more granular through native .cursorignore support.

Utilizing .cursorignore

Unlike standalone Supermaven, Cursor natively supports a project-root .cursorignore file that follows standard .gitignore globbing syntax. Any file or directory matched by .cursorignore is completely excluded from background codebase indexing, semantic embeddings, and context-window construction:

# .cursorignore - Place in project root

# 1. Environment and credential files
.env*
*.pem
*.key
*.cert
*.p12
credentials.json
service-account.json

# 2. Secret and compliance directories
secrets/
private/
compliance/
certs/

# 3. Third-party dependencies and build outputs
node_modules/
vendor/
dist/
build/
.next/
target/

# 4. Large non-code assets and database dumps
*.sql
*.sqlite
*.dump
*.csv
*.parquet
dataset/

Cursor Privacy Mode

In addition to .cursorignore, developers operating in high-compliance environments can enable Privacy Mode within Cursor:

• Zero Data Retention: Under Privacy Mode, none of your code is ever stored on remote servers, and prompts are processed ephemerally.
• SOC 2 Type II Compliance: Cursor's infrastructure is certified to maintain strict data segmentation and enterprise security standards.

Best Practices for Codebase Privacy in AI-Assisted Workflows

Configuring ignore files and editor settings is only one component of a robust security posture. Development teams should establish standard operating procedures that minimize risk by design.

┌──────────────────────────────────────────────────────────────────────────┐
│              Defense-in-Depth for AI Codebase Security                   │
├──────────────────────────────────────────────────────────────────────────┤
│  Layer 1: Secret Management                                              │
│  • Eliminate hardcoded credentials; inject secrets at runtime.           │
│                                                                          │
│  Layer 2: Repository Hygiene (.gitignore & .cursorignore)                │
│  • Ensure sensitive files are ignored by default in version control.     │
│                                                                          │
│  Layer 3: Editor Scoping (VS Code settings.json / Neovim condition())    │
│  • Suppress file watching and buffer transmission for private paths.     │
│                                                                          │
│  Layer 4: Network & Workspace Segmentation                               │
│  • Disable extensions in compliance-restricted workspaces.               │
│                                                                          │
│  Layer 5: Vendor Policy Verification                                     │
│  • Audit 7-day retention and zero-training guarantees.                   │
└──────────────────────────────────────────────────────────────────────────┘

1. Shift Secrets from Files to Runtime Environment Variables

The most reliable way to prevent an AI tool from reading a secret is to ensure the secret never exists as a plaintext file in the workspace directory.

• Secrets Managers: Use tools like Doppler, HashiCorp Vault, AWS Secrets Manager, or 1Password CLI to inject credentials directly into runtime process memory:

  # Instead of saving credentials in .env on disk:
  doppler run -- npm start
  

• Git Pre-Commit Hooks: Deploy tools such as git-secrets, trufflehog, or gitleaks in pre-commit hooks to block commits containing unintended API keys or tokens.

2. Verify Official Extension Authenticity

The Supermaven Code Policy explicitly stipulates that its 7-day retention and zero-training guarantees apply only when developers use official extensions linked from supermaven.com. Third-party forks, unofficial community wrappers, or unverified editor ports may communicate with arbitrary endpoints or lack proper data isolation. Always verify publisher signatures:

• VS Code Marketplace: Publisher supermaven (extension ID: supermaven.supermaven).
• Neovim: Repository supermaven-inc/supermaven-nvim.
• JetBrains: Vendor Supermaven, Inc..

3. Monitor Status Bar Indicators

In both VS Code and JetBrains, Supermaven displays an indicator in the lower-right status bar. This widget provides real-time visibility into:

• Indexing State: Confirms whether the repository is currently undergoing initial context ingestion.
• Account Status: Displays active plan tier (Free vs. Pro) and authentication state.
• Connectivity: Indicates whether the client is communicating with the cloud inference endpoint.

Clicking the status bar indicator allows developers to pause suggestions immediately if an unauthorized buffer is opened.

Comparative Matrix: Privacy Configuration Methods

The following matrix compares the various configuration techniques available for managing Supermaven repository context and privacy across development environments:

Practical Implementation Walkthrough

To put these strategies into practice, follow this step-by-step implementation guide when onboarding a project with sensitive data:

Step 1: Audit the Repository for Sensitive Assets

Scan the project tree for any credentials, .env files, certificates, or proprietary data sets:

find . -maxdepth 3 -name "*.env*" -o -name "*.pem" -o -name "*.key" -o -name "*secret*"

Step 2: Establish Version Control Hygiene

Ensure all identified files are placed in .gitignore:

# .gitignore
.env
.env.local
.env.production
*.pem
*.key
secrets/

Step 3: Configure Editor-Specific Safeguards

If using VS Code:

Create or update .vscode/settings.json:

{
  "files.exclude": {
    "**/.env*": true,
    "**/secrets/**": true,
    "**/*.pem": true,
    "**/*.key": true
  },
  "files.watcherExclude": {
    "**/.env*": true,
    "**/secrets/**": true
  }
}

If using Neovim:

Add path matching to your supermaven-nvim setup:

require("supermaven-nvim").setup({
  condition = function()
    local filepath = vim.api.nvim_buf_get_name(0)
    if string.match(filepath, "%.env") or string.match(filepath, "secrets/") then
      return false
    end
    return true
  end,
})

If using Cursor:

Create .cursorignore in the project root:

.env*
secrets/
*.pem
*.key

Step 4: Validate Active Status

Open your editor and verify:

1. Open a standard source file (e.g., src/index.ts). Confirm inline suggestions appear as expected.
2. Open a sensitive file (e.g., .env). Confirm that the status bar shows Supermaven disabled, paused, or that no inline suggestions are rendered.
3. Review your organization's compliance requirements to decide whether workspace-level disabling or runtime secret management is necessary for maximum assurance.

Conclusion

Supermaven's 1-million-token context window offers significant productivity gains by delivering fast, context-rich code completions across complex codebases. However, maintaining control over codebase indexing and intellectual property requires a deliberate configuration strategy. Because Supermaven does not rely on a standalone .supermavenignore file, developers must leverage the full spectrum of available controls: utilizing condition() callbacks and programmatic shutdown commands in Neovim, configuring files.exclude and watcherExclude in VS Code, disabling extensions across sensitive workspaces, and migrating to .cursorignore where applicable.

By pairing these editor-level guardrails with Supermaven's contractual 7-day retention limit, zero-training commitments, and modern runtime secret management, engineering teams can fully harness the speed of AI code completion without exposing proprietary source code or critical security credentials.