Esta página está em português. A versão em inglês é a referência principal quando houver divergência.
.cfactoryignore
Overview
.cfactoryignore is a root-level file that tells CFactory which files and folders it should not access. It uses standard .gitignore pattern syntax, but it only affects CFactory's file access, not Git.
If no .cfactoryignore file exists, CFactory can access all files in the workspace.
Quick Start
The primary mechanism for controlling file access is the permission system in cfactory.jsonc. You define tool-level permissions with glob patterns:
{
"permission": {
"read": { "*.env": "deny", "*": "allow" },
"edit": { "dist/**": "deny", "*": "allow" }
}
}
If you have an existing .cfactoryignore file, it is still supported. The IgnoreMigrator automatically converts .cfactoryignore patterns into permission deny rules on read and edit tools, so your existing rules continue to work without manual changes.
You can also exclude paths from the file watcher separately using watcher.ignore:
{
"watcher": {
"ignore": ["tmp/**", "logs/**"]
}
}
Pattern Rules
.cfactoryignore follows the same rules as .gitignore:
#starts a comment*and**match wildcards- Trailing
/matches directories only !negates a previous rule
Patterns are evaluated relative to the workspace root.
What It Affects
File access is controlled through permission-based access control. Each tool (read, edit, glob, grep, write, bash, etc.) has its own permission rules evaluated against glob patterns.
In addition to your explicit permission rules:
- Hardcoded directory ignores — 27 directories are always skipped (e.g.
node_modules,.git,dist,build,.cache,__pycache__,vendor, and others). - Hardcoded file pattern ignores — 11 file patterns are always skipped (e.g. lock files, binary artifacts).
.gitignoreand.ignorefiles are also respected when listing and searching files.
If a file is denied by a permission rule, the tool will report that access was blocked.
Configuration Details
Permission Rules
Permission rules are defined per-tool in cfactory.jsonc. Patterns are evaluated in order — the last matching rule wins:
{
"permission": {
"read": {
"*.env": "deny",
"secrets/**": "deny",
"*": "allow"
},
"edit": {
"dist/**": "deny",
"*.lock": "deny",
"*": "allow"
}
}
}
Migrating from .cfactoryignore
If you already have a .cfactoryignore file, you don't need to do anything — the IgnoreMigrator reads your existing patterns and applies them as deny rules on read and edit tools automatically. You can optionally move your rules into cfactory.jsonc for more granular control (e.g. denying edits but allowing reads).
File Watcher Exclusions
The watcher.ignore setting controls which paths the file watcher skips. This is separate from tool permissions and only affects change detection:
{
"watcher": {
"ignore": ["tmp/**", "logs/**", ".build/**"]
}
}
Checkpoints vs .cfactoryignore
Checkpoint tracking is separate from file access rules. Files blocked by .cfactoryignore or permission rules can still be checkpointed if they are not excluded by .gitignore. See the Checkpoints documentation for details.
Troubleshooting
- CFactory can't access a file you want: Remove or narrow the matching rule in
.cfactoryignore(legacy) or adjust the permission rules incfactory.jsonc(VSCode extension & CLI). - A file still appears in lists: In the legacy extension, check the setting that shows ignored files in lists and searches. In the extension & CLI, verify your permission and watcher ignore configuration.
.cfactoryignorepatterns not working in the new platform: Ensure the file is at the workspace root. The IgnoreMigrator reads it automatically — check that your patterns use valid.gitignoresyntax.