Bug
When running c3 init . --force (or any flow that regenerates project-instruction docs), the auto-generated project tree in CLAUDE.md, AGENTS.md, and GEMINI.md includes directories that are listed in .gitignore and shouldn't be part of the distributed project structure.
Reproduction
- Have any of these dirs present locally:
.pytest_cache/
.ruff_cache/
.vscode/
*.egg-info/ (e.g. from pip install -e .)
- Run
python cli/c3.py init . --force --ide claude --mcp-mode direct.
- Inspect the regenerated
CLAUDE.md (or AGENTS.md / GEMINI.md).
Expected
The project-tree section should show only files/dirs that would be part of a clean distribution — i.e., respect .gitignore.
Actual
Stale cache/build artifacts appear in the tree:
.pytest_cache/
.gitignore
CACHEDIR.TAG
README.md
v/
.ruff_cache/
.gitignore
CACHEDIR.TAG
0.15.12/
.vscode/
mcp.json
settings.json
...
code_context_control.egg-info/
SOURCES.txt
dependency_links.txt
entry_points.txt
...
These then ship to end users via the project-instruction docs, polluting their initial impression of the project structure.
Additional symptom
The doc generator also appears to cache the directory listing somewhere (likely via services/file_memory.py or services/claude_md.py). Even after deleting .ruff_cache/ and code_context_control.egg-info/ from disk and re-running c3 init --force, the stale entries persist in the regenerated docs. So the fix needs to address both:
- The walker that builds the tree should respect
.gitignore patterns.
- The file-memory cache should invalidate (or at least re-scan) when directories listed in it no longer exist on disk.
Likely fix location
services/claude_md.py — the doc generator (probably builds the tree section)
services/file_memory.py — the cache that holds the directory listings
A minimal patch would teach the tree-walker to read .gitignore and skip matched paths. The standard library pathspec package handles this exactly, or a small hand-rolled implementation since we already only need the simple pattern subset (.dir/, *.ext).
Workaround
Edit the generated docs by hand to strip the offending lines (what was done for v2.28.0 — see the post-release commit at 73b3708).
Severity
Low — cosmetic only, but visible to every user who runs c3 init.
Bug
When running
c3 init . --force(or any flow that regenerates project-instruction docs), the auto-generated project tree inCLAUDE.md,AGENTS.md, andGEMINI.mdincludes directories that are listed in.gitignoreand shouldn't be part of the distributed project structure.Reproduction
.pytest_cache/.ruff_cache/.vscode/*.egg-info/(e.g. frompip install -e .)python cli/c3.py init . --force --ide claude --mcp-mode direct.CLAUDE.md(orAGENTS.md/GEMINI.md).Expected
The project-tree section should show only files/dirs that would be part of a clean distribution — i.e., respect
.gitignore.Actual
Stale cache/build artifacts appear in the tree:
These then ship to end users via the project-instruction docs, polluting their initial impression of the project structure.
Additional symptom
The doc generator also appears to cache the directory listing somewhere (likely via
services/file_memory.pyorservices/claude_md.py). Even after deleting.ruff_cache/andcode_context_control.egg-info/from disk and re-runningc3 init --force, the stale entries persist in the regenerated docs. So the fix needs to address both:.gitignorepatterns.Likely fix location
services/claude_md.py— the doc generator (probably builds the tree section)services/file_memory.py— the cache that holds the directory listingsA minimal patch would teach the tree-walker to read
.gitignoreand skip matched paths. The standard librarypathspecpackage handles this exactly, or a small hand-rolled implementation since we already only need the simple pattern subset (.dir/,*.ext).Workaround
Edit the generated docs by hand to strip the offending lines (what was done for v2.28.0 — see the post-release commit at 73b3708).
Severity
Low — cosmetic only, but visible to every user who runs
c3 init.