Security¶

This page is a security overview for Cortex Code Desktop. It explains the trust boundaries the product enforces, the recommended baseline for everyday use, and the limitations you should know about before granting the agent broader permissions.

For the per-feature controls, see:

• Permission modes
• Plugins
• Skills
• MCP support
• Hooks
• Subagents
• Agentic Browser
• Scheduled tasks
• Onboarding and authentication

The trust model¶

Cortex Code Desktop enforces several distinct trust boundaries. Each one has its own approval flow and its own scope; together they decide what the agent and any extensions can do on your behalf.

Recommended security baseline¶

Apply these defaults for everyday use:

• Use Default Approvals. The agent prompts you before each tool call. Bypass Approvals auto-approves every tool call; reserve it for isolated environments.
• Use Plan Mode for unfamiliar prompts. Plan Mode is read-only and lets you confirm the approach before any side effects. See Agent mode and Plan mode.
• Review file edits before accepting them. Tighten the auto-approve glob list for sensitive files in your repo (package.json, .env, secrets, build scripts).
• Scope tool approvals to sessions. Pick “Allow once” or “Allow for session” rather than “Always allow” when you are not sure.
• Vet plugins, skills, and MCP servers before you trust them. Read the manifest, the skills it bundles, and the MCP servers and hooks it registers. Pin sources to specific commits or stage paths whenever you can.
• Apply auto-updates promptly. See Auto-update for why this matters and how stale installs are handled.
• Don’t install unnecessary extensions. Extensions come from third-party developers and contain code that runs with the same privileges as Cortex Code Desktop.

File permissions¶

If you have a connections.toml file, restrict it and the agent’s data directory to your user only and add it to .gitignore:

[ -f ~/.snowflake/connections.toml ] && chmod 600 ~/.snowflake/connections.toml
chmod 700 ~/.snowflake/cortex
chmod 700 ~/.snowflake/cortex/conversations
echo "~/.snowflake/connections.toml" >> ~/.gitignore

Credentials¶

We recommend using authenticator = "oauth_authorization_code" as the default authentication method to avoid plaintext credential storage. See Onboarding and authentication for the supported methods.

For MCP servers:

• Use OAuth where supported. The token lands in OS-native secret storage and refreshes automatically; mcp.json never sees it.

• For static API keys, use ${input:...} with password: true. The desktop prompts you on first run and stores the value encrypted in workspace state, not in mcp.json:

  Copy codeExpand code block

  {
    "mcpServers": {
      "my-server": {
        "command": "npx",
        "args": ["-y", "my-mcp-server"],
        "env": { "API_KEY": "${input:api-key}" }
      }
    },
    "inputs": [
      { "id": "api-key", "type": "promptString", "password": true }
    ]
  }

  Show lessSee more

  Scroll to top

• Authorization headers in mcp.json are stored as plaintext on disk.

Roles and least privilege¶

Cortex Code Desktop runs SQL with whatever role the active connection specifies. The role field in connections.toml is optional; if you leave it out, the session uses your Snowflake user’s default role.

Cortex Code Desktop does not restrict secondary roles on its own.

Conversation history¶

Cortex Code Desktop persists conversations under ~/.snowflake/cortex/conversations/. They include any file content, tool output, and SQL the agent saw.

Workspace restricted mode¶

Use restricted mode when operating on an untrusted codebase. When a workspace is untrusted, Cortex Code Desktop behaves in the following way:

• Editor Mode uses the persisted trusted-folders list. An untrusted folder runs in restricted mode: chat is blocked, and workspace-scope hooks, MCP servers, subagents, project skills, and prompt files are disabled. Plain editing and the integrated terminal still work. The status bar shows “Trusted” or “Restricted Mode”.
• Agent Mode uses the Agent Manager project list. Adding a folder prompts the “Trust this folder?” confirmation; on confirm the folder is added as a trusted Agent Mode project.
• Editor Mode and Agent Mode trust are linked, but asymmetrically:
  • Trusting a project in Editor Mode does not automatically add it to Agent Mode. It has to be added in Agent Mode separately.
  • Adding and trusting a project in Agent Mode automatically marks it as trusted in Editor Mode.
  • Distrusting a project in Editor Mode removes it from Agent Mode.

Extensions¶

Cortex Code Desktop ships with Open VSX as its extension store with a limited set of extensions available to users.

Extensions installed through the Extensions panel are auto-updated.

Sideloading extensions¶

Users can sideload extensions by installing a VSIX file directly, bypassing the Extensions panel. Be cautious when sideloading from untrusted sources.

Auto-update¶

Cortex Code Desktop checks for updates, downloads them, and prompts you to install. Significantly outdated installations are required to update.

Drift detection¶

Once a workspace is trusted, most config sources reload silently when their files change. This includes skills, hooks, and, in some cases, MCP server configurations.

Sandbox¶

The agent terminal sandbox wraps every terminal command the agent runs inside an isolated sandbox process. Enabling it is the recommended extra layer of protection when you want to limit what shell commands the agent can execute, even in trusted workspaces.

Enable the sandbox¶

1. Open Settings (gear icon or Cmd/Ctrl+,).
2. Search for chat.agent.sandbox.
3. Set chat.agent.sandbox.enabled to "on".

Or add it directly to your settings.json:

{
  "chat.agent.sandbox.enabled": "on"
}

When the sandbox is active, agent-initiated terminal commands are wrapped at the executor level. Commands you run manually in the integrated terminal are not affected.

Limitations¶

• The sandbox applies only to terminal commands the agent runs via the Bash tool. It does not restrict file edits, SQL execution, or MCP tool calls.
• Sandbox behavior depends on OS-level sandboxing capabilities and may vary between macOS, Windows, and Linux.
• Some agent workflows that depend on shell side-effects (for example, installing packages that affect the current shell session) may behave differently inside the sandbox.

Cortex Code Desktop will adopt the VSCode native agent sandbox and agent-tools framework as those features stabilize upstream. For more information, see VSCode agent tools and VSCode Copilot security.

Enterprise policies¶

Administrators can centrally configure Cortex Code Desktop with a managed-settings file:

Today the file can:

• enforce a permission allowlist and denylist (covering plugin, skill, and MCP tool patterns via permissions.onlyAllow / permissions.deny)
• set the default permission mode (permissions.defaultMode)
• force no-history mode (forceNoHistoryMode) so conversations aren’t persisted
• show a managed-by-organization banner with custom text
• hide the dangerous-options UI