How to Configure Filesystem MCP in Continue.dev

Stdio Process Lifecycle and Protocol Framing

When Continue starts a local filesystem MCP server, it spawns Node.js as a local child process. The IDE extension and the MCP server communicate through standard input (stdin) and standard output (stdout) using JSON-RPC 2.0 messages.

Because stdout carries machine-readable protocol frames, any extraneous text written to standard output breaks the JSON-RPC parser. Shell scripts that print greeting banners, global npm version checks, or debugging console.log statements in custom wrappers corrupt the transport stream. All diagnostics and logging must route to standard error (stderr).

The spawned process shares the lifecycle of the IDE window. If VS Code or JetBrains reloads, or if the Continue extension restarts, the child process terminates immediately.

Directory Boundaries and Access Sandboxing

Security in @modelcontextprotocol/server-filesystem centers on directory allow-listing. When the server launches, Continue passes explicit directory paths as command-line arguments.

The server verifies every incoming file operation against these declared boundaries. Before reading, editing, or listing any target, the server resolves all symbolic links to their canonical absolute paths on disk. If a requested path resolves to a location outside the declared roots, the server rejects the request with an access denial error. This mechanism prevents language models from inspecting sensitive system paths such as ~/.ssh or /etc.

Declaring the Server in config.json

For environments using config.json, add the filesystem entry inside the top-level mcpServers array. Continue requires explicit command-line arguments specifying the directories the server can touch:

{
  "models": [
    {
      "title": "Claude 3.5 Sonnet",
      "provider": "anthropic",
      "model": "claude-3-5-sonnet-latest"
    }
  ],
  "mcpServers": [
    {
      "name": "filesystem",
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/username/projects/specs",
        "/Users/username/projects/shared-docs"
      ]
    }
  ]
}

Replace /Users/username/projects/specs with the absolute path to your local directory. Do not use tilde abbreviations (~) in the arguments list, because Node.js child process execution does not perform shell expansion on arguments.

Declaring the Server in config.yaml

In modern Continue installations using config.yaml, the same server definition translates into clean YAML syntax:

name: Developer Configuration
version: 1.0.0
schema: v1

mcpServers:
  - name: filesystem
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-filesystem"
      - "/Users/username/projects/specs"
      - "/Users/username/projects/shared-docs"

If your system PATH does not resolve npx inside the IDE environment, substitute the absolute path to the executable, such as /usr/local/bin/npx or /opt/homebrew/bin/npx on macOS.

Enabling Agent Mode and Tool Permissions

Configuring the server in config.yaml or config.json makes the tools available to Continue, but the extension will not execute them in standard autocomplete or vanilla chat mode. Model Context Protocol tools execute exclusively when Continue operates in Agent Mode.

To activate Agent Mode:

1. Open the Continue sidebar using Cmd + L (macOS) or Ctrl + L (Windows and Linux).
2. Locate the mode selector dropdown near the chat input box.
3. Switch from Chat to Agent.
4. Enter your prompt, such as "Read the deployment guide in the specs folder and draft an architectural overview."

Continue checks tool configurations and displays confirmation dialogues when the model requests write or edit operations. Tool permissions in ~/.continue/permissions.yaml allow teams to disable destructive primitives like write_file or move_file while keeping read-only tools active.

Virtual File Stubs and Dataless Placeholders

Desktop sync clients for Google Drive, Dropbox, Box, and OneDrive use virtual file systems to conserve local disk space. On macOS, this relies on Apple's FileProvider framework, which mounts cloud folders inside ~/Library/CloudStorage/. On Windows, sync clients use the Cloud Files API (Windows Projected File System).

These systems display files in the file explorer as if they were fully stored on disk, but the files exist as dataless placeholders. A dataless stub stores directory metadata (filename, size, modification date) but allocates zero physical blocks on the local solid-state drive until an application explicitly requests its contents.

When a human double-clicks a dataless file, the operating system intercepts the call and downloads the file from cloud servers. But when Continue's filesystem MCP server scans a directory, it executes standard POSIX system calls (readdir, stat, open).

POSIX system calls interact poorly with virtual file stubs:

1. Zero-Byte Reads: In some configurations, POSIX readFile operations return an empty buffer without triggering an on-demand download. The agent receives zero bytes and assumes the document is empty.
2. Hydration Deadlocks: If the sync client cannot immediately download the file due to network latency, the OS filter driver hangs the reading thread, leading to POSIX timeout errors (EDEADLK).
3. Accidental File Corruption: If an agent attempts to edit a dataless file by writing updated content, it can replace the remote cloud stub with a truncated local file, damaging team assets.

Thread Blocking on Unindexed Recursive Scans

When a language model needs to answer a question about a project, it often begins by calling search_files or directory_tree to discover relevant files.

In @modelcontextprotocol/server-filesystem, file search executes as a synchronous, unindexed traversal over every directory within the allowed path. If the target folder contains node modules, large git histories, or tens of thousands of synced documents from a corporate cloud drive, the Node.js process must stat every individual file sequentially.

Unindexed directory scanning can delay IDE response for ten seconds or more. During this crawl, the single-threaded Node.js event loop blocks on synchronous filesystem I/O. The Continue sidebar becomes unresponsive, the agent pauses execution, and the IDE extension host can freeze while waiting for filesystem operations to complete.

Reading raw files directly into the conversation also consumes massive context window capacity. A local filesystem server reads whole files into the LLM prompt. Ingesting multiple technical manuals or design specifications quickly drains context limits, raises API token costs, and degrades reasoning quality.

Maintaining Existing Storage with Scheduled Cloud Sync

Engineering teams already maintain documentation, contract specifications, and architectural diagrams across established enterprise repositories like Google Drive, Dropbox, Box, OneDrive, and SharePoint. Requiring engineers to duplicate these folders onto local laptops wastes disk space and creates version divergence.

Fast.io bridges existing storage into indexed workspaces. Cloud Sync connects Google Drive, Dropbox, Box and OneDrive folders to a workspace, one-way or two-way, on a schedule or on demand (never continuous, live or real-time; SharePoint libraries connect through the OneDrive connector).

Once files land in a Fast.io workspace, Intelligence Mode automatically indexes their contents for hybrid search. Hybrid search combines full-text lexical search, semantic vector retrieval, and metadata value filtering. When an AI agent needs context, it does not scan unindexed folders; it queries the workspace index and retrieves only the precise paragraphs and code blocks relevant to the prompt. For structured documents like technical specifications, schemas, or tabular assets, Metadata Views extract typed attributes into filterable schemas that agents can query directly via MCP.

The connector comparison is published at fast.io/benchmarks/ and that page is the only place its numbers live. In that published testing, Fastio was measured the fastest and the lowest cost of the providers tested. Every measured row evaluated that provider's native connector in Claude Cowork; no row evaluated a local stdio server, a Files-On-Demand stub, or SharePoint, and SharePoint was not measured at all.

Configuring Continue.dev with Remote Streamable HTTP MCP

Connecting Continue to an intelligent Fast.io workspace replaces the local stdio configuration with a remote Streamable HTTP endpoint.

Coding agents in an IDE, including Continue, Cursor, Claude Code, and VS Code, connect to the dedicated coding endpoint at https://mcp.fast.io/mcp/code. Review the Fast.io MCP documentation for setup specifics. For headless automation, developers can review the agent developer reference and explore architectural patterns at storage for agents.

To configure Continue with Fast.io, update ~/.continue/config.yaml:

name: Developer Configuration
version: 1.0.0
schema: v1

mcpServers:
  - name: fast-io-workspace
    type: streamable-http
    url: https://mcp.fast.io/mcp/code

When Continue connects to https://mcp.fast.io/mcp/code, interactive sessions use OAuth 2.0 authentication. The browser opens a review screen where you select your organization, workspace, and permissions (Read Only or Read & Write). Headless scripts or background workers pass an API key as an Authorization: Bearer <api_key> header.

Every file in Fast.io retains full version history, and a detailed activity log records changes (uploads, edits, moves, deletions, and permissions updates) across team members and automated agents. Permissions are configured per organization, workspace, and share, ensuring agents only access designated workspace content.

Plan Tiers and Capacity Allocations

Fast.io organizes shared workspaces with transparent capacity boundaries:

Monthly plans start with a 14-day free trial that requires a credit card. Check Fast.io pricing for complete subscription details.