Knowledge base

Generated from src/knowledge/ by npm run docs:knowledge; do not edit by hand. Notes on verified facts are in the modules.

Status: verified was read in an official source, uncertain is supported but not conclusive, disputed means official sources disagree and every variant is shown. "none" means the agent is known not to have the feature, unless the status says otherwise.

Disputed and uncertain facts

• Cursor, Configuration, winner first (uncertain): Cursor documents no single configuration order, only one per feature; this is the order for hooks, the only one that names files at every scope (team hooks sit between managed and project but live in the dashboard). Sandbox: per-user < per-repo < team-admin < hardcoded (https://cursor.com/docs/reference/sandbox). Permissions: team dashboard, then permissions.json, then IDE settings (https://cursor.com/docs/reference/permissions). Rules: Team, Project, User (https://cursor.com/docs/rules). The CLI configuration page does not rank its files (https://cursor.com/docs/cli/reference/configuration), and the MCP page does not say which file wins for a server defined in both (https://cursor.com/docs/mcp). source
• Cursor, Automatic start (uncertain): Cursor's own documentation never mentions tasks.json or folderOpen. This page says only that workspace trust "is disabled by default". The behavior comes from a third-party report, updated 2026-05-01, that folderOpen tasks run when a folder is opened (https://www.oasis.security/blog/cursor-security-flaw); it is not an official source and was not tested. Field names are VS Code's (https://code.visualstudio.com/docs/debugtest/tasks), and its setting task.allowAutomaticTasks may also apply. The format is written as jsonc from VS Code convention and was not read on either page. Cursor has a second, documented mechanism that this field cannot hold: a workspaceOpen hook, listed under hooks. source
• Cursor, Subagents and commands (uncertain): Subagents are verified on this page: project wins over user for one name, and .cursor wins over .claude and .codex. Commands are the uncertain part: the project path comes only from a 2025 changelog (https://cursor.com/changelog/1-6), and no current documentation page for them was found. Cursor's skills migration text confirms user-level commands exist, but their path was not read on an official page, so ~/.cursor/commands is left out. Commands may have frontmatter; the plugin reference documents that for plugins only. source
• OpenAI Codex CLI, Skills (disputed): The documentation lists only .agents/skills roots, while the loader also scans .codex/skills next to each project config layer and the deprecated ~/.codex/skills. Scan every path of both variants. Codex follows symlinked skill folders. source, source
• Gemini CLI, Automatic start (uncertain): No documented file runs a command when a folder is opened. The closest is a SessionStart hook, which fires on startup, resume and /clear. hookRegistry.ts loads project hooks only in a trusted folder, and then warns once and marks them trusted, with no approval step. Which matcher strings SessionStart accepts is not documented, so startup as a value is the source field, not a confirmed matcher. source
• Gemini CLI, context file names (disputed): The documentation says context.fileName lets one "specify a different name or a list of names", which reads as a replacement of GEMINI.md; the code adds the names to the current ones: config.ts calls setGeminiMdFilename(settings.context.fileName), which "Adds one or more filenames to the current context filenames" and keeps the default. agentcurfew reads GEMINI.md and the configured names, so that neither reading hides a file. Each name is trimmed, normalized and may hold subfolders (memoryTool.ts: "Sanitize to prevent path traversal while allowing subdirectories"); memoryDiscovery.ts looks for it in ~/.gemini, in the working directory and its parents up to the project root, and in subfolders. Workspace settings apply only in a trusted folder. source, source
• GitHub Copilot in VS Code, Skills (disputed): The two pages disagree on whether the Copilot harness reads .agents/skills and ~/.agents/skills. Both variants hold the Copilot harness only: Local sessions also read .agents/skills, .claude/skills, ~/.agents/skills and ~/.claude/skills. The deprecated chat.agentSkillsLocations adds locations for Local sessions. source, source
• GitHub Copilot in VS Code, Permissions (uncertain): The keys and values are documented here and in https://code.visualstudio.com/docs/agents/reference/ai-settings, as flat setting names, not nested paths. Not settled: whether each works from .vscode/settings.json. Neither page states a scope, and the security page advises only against granting permissions at workspace level. Issue reports on microsoft/vscode conflict, so .vscode/settings.json is listed so that a scanner still looks there. chat.permissions.default is experimental; the page lists its values as default, autoApprove and autopilot. chat.tools.edits.autoApprove appears in the settings reference, not on the approvals page. Read on 2026-11-07: in .vscode/mcp.json a server with sandboxEnabled true has its tool confirmations "auto-approved because the server runs in a controlled environment" (https://code.visualstudio.com/docs/agents/reference/mcp-configuration); task.allowAutomaticTasks on runs automatic tasks "when opening a trusted workspace, without prompting", and the tasks page says to "add it to your user or workspace settings" (https://code.visualstudio.com/docs/debugtest/tasks). source
• Windsurf (Devin Desktop), MCP servers (disputed): A project file exists now (https://docs.devin.ai/cli/extensibility/mcp/configuration.md); which file wins for one server is not documented. Versions before v3000.3 kept servers under mcpServers in .devin/config.json, .devin/config.local.json and the user config.json, and newer ones migrate them on startup (same page, read on 2026-11-07), so those files are read too. Sources disagree on the legacy user file. read_config_from.windsurf defaults to true, and read_config_from also imports .mcp.json, .cursor/mcp.json and other tools' files; those belong to their own agents, except OpenCode's opencode.json and Zed's .zed/settings.json (key context_servers), which agentcurfew does not read yet, and ~/.claude/mcp_servers.json (https://docs.devin.ai/cli/reference/configuration/read-config-from.md, read on 2026-11-07). The docs read in phase 1 name url for remote servers and do not mention serverUrl, while a search summary of https://docs.windsurf.com/windsurf/cascade/mcp on 2026-11-06 (the page itself could not be fetched) says a remote server needs serverUrl or url; both are read. The field in legacy files could not be read from an official page. source, source
• Windsurf (Devin Desktop), Automatic start (uncertain): Inferred from VS Code, not from Devin Desktop docs: the FAQ calls its data directory VS Code-derived and its docs say nothing about automatic tasks. In VS Code the task.allowAutomaticTasks setting gates them, and they never run in untrusted workspaces. Separately, Desktop documents devcontainer.json lifecycle commands, where initializeCommand runs on the host once the folder is trusted (https://docs.devin.ai/desktop/advanced). source
• Windsurf (Devin Desktop), Subagents and commands (disputed): Sources disagree on whether workflows still run: the workflows page documents them and calls them Cascade-only, unsupported by Devin Local, while the changelog says v3.9.19 (2026-09-08) removed Cascade and Devin Local is the only agent (https://docs.devin.ai/desktop/changelog). The Cascade reference, read on 2026-11-07, sides with the changelog: "Devin Desktop no longer starts new Cascade conversations and no longer opens old ones" (https://docs.devin.ai/desktop/cascade.md). Files may therefore be inert on current versions and live on older ones, so both are kept. Skills are invoked as /skill-name. source, source
• Cline, Configuration, winner first (uncertain): Only the rules page states an order: workspace rules win over global ones. The order inside each group is the search order of resolveRulesConfigSearchPaths in the SDK, not a documented ranking. Cline has no single layered settings chain: the config page says only that global and project config work together, MCP servers and settings exist only at user level, and skills go the other way round (a global skill beats a project skill of the same name). source
• Cline, Permissions (uncertain): All three files are user-level; no project-level permissions file was found, and https://docs.cline.bot/features/auto-approve.md describes only the UI, including YOLO mode. Inferred, not stated: that toolAutoApprove in global-settings.json turns prompts off (only its name and type were read), and that autoApprovalSettings is stored in globalState.json (https://github.com/cline/cline/blob/ea16751d6ae3ae1e443681994906bf29cbc45039/apps/vscode/src/shared/storage/state-keys.ts defines the key and https://github.com/cline/cline/blob/ea16751d6ae3ae1e443681994906bf29cbc45039/apps/vscode/src/shared/storage/storage-context.ts names the file). No key for YOLO mode was found in state-keys.ts. https://docs.cline.bot/cli/cli-reference.md says the CLI has no allow or deny list for shell commands, and --auto-approve defaults to true outside ACP mode. Administrators can set yoloModeAllowed by remote configuration, not by a file. source
• Cline, Automatic start (uncertain): Types: the trigger is the file's presence, not a field; enabled defaults to true, so a spec that omits it runs, and the command is an agent prompt rather than a shell command. Read from code, never run. https://github.com/cline/cline/blob/ea16751d6ae3ae1e443681994906bf29cbc45039/sdk/packages/core/src/cron/specs/cron-spec-parser.ts defaults mode to yolo and requires prompt and workspaceRoot; https://github.com/cline/cline/blob/ea16751d6ae3ae1e443681994906bf29cbc45039/sdk/packages/core/src/cron/runner/cron-materializer.ts queues every enabled one-off spec; https://github.com/cline/cline/blob/ea16751d6ae3ae1e443681994906bf29cbc45039/sdk/packages/core/src/cron/runner/cron-runner.ts sets autoApprove on all tools. ARCHITECTURE.md says normal CLI and hub startup watches the workspace .cline/cron without opting in, but https://docs.cline.bot/sdk/guides/scheduled-agents.md names only ~/.cline/cron, and the hub wiring itself was not read. Unknown: whether workspaceRoot must match the watched workspace, and whether a provider or anything else stops a fresh clone from running. Not checked for the VS Code extension. .cline/cron/reports holds generated reports. No field that starts a command on folder open was found. cron-reconciler.ts reads the global ~/.cline/cron by default; the workspace folder is used only when the host passes scope workspace (main at ea16751), which disagrees with ARCHITECTURE.md, so both folders stay listed. source

Claude Code

Cursor

OpenAI Codex CLI

Gemini CLI

GitHub Copilot in VS Code

Windsurf (Devin Desktop)

Cline

Deprecated files and settings

Hooks and commands

Shared formats