Indexing in VSCode Terminal under WSL Causes Server Timeout and Crash

[bashandbone]

Problem

When running CodeWeaver within a VSCode terminal inside WSL, the indexing process—especially during processor-intensive embedding—frequently causes the VSCode server to crash and WSL to time out. This issue happens despite CodeWeaver explicitly lowering its process priority (10+ nice) and applying logic to reduce the number of processors and threads on WSL (see codeweaver.common.utils.procs).

Details

• Crashes specifically occur when indexing in a VSCode terminal running under WSL.
• These crashes appear tied to the embedding phase (high CPU load).
• Measures to reduce priority and thread count do not prevent the problem.
• Only tested so far on a personal laptop; not yet confirmed on other hardware/configurations.

Temporary Workaround

While CodeWeaver can work with VSCode, for a more stable experience, run it either:

• Directly in a WSL terminal (outside of VSCode)
• In a native Linux or Windows environment

If you've already indexed your codebase, the issue may not occur.

Steps to Reproduce

1. Use VSCode within WSL.
2. Start CodeWeaver indexing from a VSCode terminal.
3. Observe server crash during embedding phase.

Environment

• CodeWeaver running in: VSCode terminal inside WSL
• WSL: (version and hardware specifics can be added)
• Personal laptop (additional configs helpful for future debugging)

References

Relevant logic: codeweaver.common.utils.procs

---

For further insights, more testing on diverse hardware/setups is recommended.

[github-actions]

Claude finished @bashandbone's task —— View job

---

Issue Analysis Complete

• Review and summarize the issue
• Examine related code
• Search for related issues or discussions
• Identify potential fixes
• Suggest relevant labels
• Provide summary and recommendations

---

Summary

This issue reports that CodeWeaver crashes VSCode's integrated terminal when running within WSL during the indexing phase, specifically during CPU-intensive embedding operations. The issue mentions that CodeWeaver "explicitly lowers its process priority (10+ nice) and applies logic to reduce the number of processors and threads on WSL" via codeweaver.common.utils.procs, but this module does not exist in the codebase.

Key Findings

Missing Code

The referenced module codeweaver.common.utils.procs does not exist. This appears to be a documentation error in the issue - the mitigation measures mentioned have not been implemented yet.

Current Resource Management

The existing code has:

• Parallel chunking (engine/chunker/parallel.py): Uses ProcessPoolExecutor with max_workers limited to CPU count, defaults to 4 workers
• FastEmbed embedding (providers/embedding/providers/fastembed.py): Uses multiprocessing.cpu_count() threads by default
• Concurrency settings (config/chunker.py): ConcurrencySettings with max_parallel_files: 4 default

What's Missing

• No WSL detection
• No process priority (nice) adjustment
• No adaptive thread reduction for constrained environments
• No memory pressure monitoring

Related Issues

No directly related issues found in this repository. This is the first reported WSL-specific stability issue.

Potential Fixes

1. Create the procs utility module (Medium effort)

Implement the referenced module with:

• WSL environment detection (/proc/version check for "microsoft" or "WSL")
• Process priority adjustment via os.nice()
• Adaptive CPU count reduction for WSL (e.g., use 50-75% of available CPUs)
• Memory pressure monitoring

Relevant code locations:

• src/codeweaver/common/utils/ - Add new procs.py module
• src/codeweaver/providers/embedding/providers/fastembed.py:51 - Modify fastembed_all_kwargs() to use adaptive thread count
• src/codeweaver/engine/chunker/parallel.py:144 - Modify to use adaptive worker count

2. Configuration-based mitigation (Low effort)

Add WSL-specific presets to the configuration system:

• Lower default max_parallel_files when WSL is detected
• Reduce default thread count for embedding providers
• Add wsl_safe_mode configuration option

3. VSCode-specific detection (Low effort)

Detect VSCode terminal environment via TERM_PROGRAM or VSCODE_* environment variables and apply additional constraints.

Difficulty Assessment

Implementation difficulty: Medium

Core implementation requires:

• WSL detection utility
• Adaptive resource limiting
• Integration with existing configuration system
• Testing across various WSL configurations

Impact on existing functionality: Low-Medium

• Changes affect resource allocation, not core logic
• May reduce performance on WSL but improve stability
• Backward compatible with non-WSL environments

Suggested Labels

This issue already has appropriate labels:

• bug ✓
• indexer ✓
• performance ✓

Recommendations

1. Immediate: Update the issue description to note that codeweaver.common.utils.procs is proposed but not yet implemented
2. Short-term: Implement basic WSL detection and conservative defaults
3. Long-term: Add comprehensive resource monitoring and adaptive throttling

The workaround mentioned (running outside VSCode terminal) is valid for now. Additional testing on different hardware/WSL configurations would help characterize the severity and conditions that trigger the crash.

---