Framework reload memory script fails on Windows with mixed path separators

[jcmrs]

Framework reload memory script fails on Windows with mixed path separators

Problem

The framework reload protocol fails to execute the memory script on Windows due to mixed path separators in the command.

Error

When running /framework:reload, the memory script execution fails:

node C:\Users\jcmei\.claude\plugins\cache\axivo\framework\1.0.0/skills/framework-initialization/scripts/memory

Error: Cannot find module 'C:\Development\MCP\INTERNAL\claude-collab\Usersjcmei.claudepluginscacheaxivoframework1.0.0\skills\framework-initialization\scripts\memory'

Root Cause

The reload command uses mixed path separators (backslashes and forward slashes):

• Path starts with: C:\Users\jcmei\.claude\plugins\cache\axivo\framework\1.0.0/
• Notice: backslashes (\) at the beginning, forward slash (/) after version

Node.js on Windows cannot resolve this correctly and attempts to interpret it relative to the current working directory, resulting in the mangled path shown in the error.

Expected Behavior

The path should use consistent Windows backslashes:

node C:\Users\jcmei\.claude\plugins\cache\axivo\framework\1.0.0\skills\framework-initialization\scripts\memory

Impact

Severity: Low

• Framework reload still completes successfully by reading instructions.json and memory.json directly
• Memory script provides timestamp information (supplementary, not critical)
• Core framework functionality is not affected

Location

File: plugins/framework/commands/reload.md
Line: Command template using ${CLAUDE_PLUGIN_ROOT} variable

Suggested Fix

Ensure path construction uses platform-appropriate separators throughout the reload command template, or normalize the path before passing to Node.js.

Environment

• OS: Windows 11
• Node.js: v24.7.0
• Framework Version: 1.0.0
• Commit: 1883ab9

[jcmrs]

Root Cause Analysis

Found the source of the path separator mixing in reload.md line 43:

node ${CLAUDE_PLUGIN_ROOT}/skills/framework-initialization/scripts/memory

What happens:

• ${CLAUDE_PLUGIN_ROOT} expands to: C:\Users\jcmei\.claude\plugins\cache\axivo\framework\1.0.0 (Windows backslashes)
• Template hardcodes: /skills/framework-initialization/scripts/memory (Unix forward slashes)
• Final command: node C:\Users\jcmei\.claude\plugins\cache\axivo\framework\1.0.0/skills/framework-initialization/scripts/memory

Why Node.js fails:

When Node.js on Windows sees a path starting with a Windows absolute path followed by a forward slash, it interprets the forward-slash portion as relative to the current working directory instead of appending to the base path.

Node.js attempts:

cwd + /skills/framework-initialization/scripts/memory

Instead of:

C:\Users\jcmei\.claude\plugins\cache\axivo\framework\1.0.0\skills\framework-initialization\scripts\memory

Potential fixes:

1. Use backslashes in template:

   node ${CLAUDE_PLUGIN_ROOT}\skills\framework-initialization\scripts\memory

2. Use Node.js path resolution:

   node -e "require('path').join(process.env.CLAUDE_PLUGIN_ROOT, 'skills', 'framework-initialization', 'scripts', 'memory')"

3. Platform-agnostic approach:
   Detect OS and use appropriate separator, or normalize path before execution.

[jcmrs]

Broader Pattern: Unix Predisposition in AI Assistants

This path separator bug is part of a larger pattern of Unix assumptions that cause issues on Windows.

Git Command Chaining Issues

Common pattern that fails on Windows:

git pull && git commit -m "message"
git fetch origin && git pull origin main

Why this fails:

1. Git pull = fetch + merge (creates .git/index.lock)
2. Windows mandatory locking vs Unix advisory locking
3. Lock file timing race condition:

   git pull (creates .git/index.lock)
     ↓
   pull completes, tries to delete lock
     ↓
   Windows: lock file persists longer ← TIMING WINDOW
     ↓
   git commit tries to create .git/index.lock
     ↓
   ERROR: File exists (Another git process seems to be running)
   

Unix vs Windows behavior:

• Unix: Lock files released almost instantly, advisory locking, && chains work reliably
• Windows: Lock files persist longer, mandatory locking, timing assumptions don't hold

Unix Predisposition Evidence

1. Path separators: Framework template uses / (Unix) instead of \ (Windows)
2. Command chaining: AI assistants assume cmd1 && cmd2 works seamlessly (Unix pattern)
3. File locking: Commands assume instant lock release (Unix behavior)

Recommendations for Windows Compatibility

For the framework:

1. Use platform-agnostic path construction
2. Detect OS and use appropriate separators
3. Document Unix-only features explicitly

For AI assistants on Windows:

1. Avoid chaining Git operations with &&
2. Execute Git commands sequentially with explicit waits
3. Check for lock files before proceeding to next operation

Example safe pattern:

# Instead of: git pull && git commit
git pull
# Wait for completion, then separate command:
git commit -m "message"

This Unix bias is systematic across AI assistants (Claude, Gemini, etc.) because training data is heavily Unix/Linux-oriented.

[jcmrs]

Validation from Community: This is a Known Pattern

Web search reveals extensive documentation of Windows path issues with Claude Code, confirming this is not an isolated bug but a systemic pattern.

Documented Claude Code Windows Issues

PATH Environment Variable Corruption:

• Issue #6463 - Claude Code deletes entire PATH when attempting to append paths
• Commands like setx PATH "%PATH%;C:\Program Files\tool" fail variable expansion

WSL Path Prefix Confusion:

• Issue #9580 - Uses WSL-style /mnt/c/ paths on native Windows
• WSL-specific convention incorrectly applied outside WSL environment

Git Bash Path Conversion:

• Issue #2602 - Windows paths not properly converted in Git Bash
• Same command chaining failures observed in this issue

Community Workarounds:

• Windows Setup Repository - Production-ready setup solving path translation
• Multiple guides needed just to make Claude Code work reliably on Windows

Pattern Scope

The Unix bias extends beyond simple path separators:

• Forward slash / vs backslash \ (this issue)
• WSL path prefixes /mnt/c/ on native Windows
• PATH environment variable expansion
• Git Bash path translation
• Command chaining assumptions (git pull && git commit)

LLM Bias Research (2024)

Recent academic research documents bias in LLM code generation:

• Bias Testing and Mitigation in LLM-based Code Generation
• Bias Unveiled: Investigating Social Bias

However, research focuses on social bias (gender, race) rather than operating system bias. No published research specifically addresses Unix/Linux bias in training data, despite clear evidence in production systems.

Potential Mitigation: Project-Specific Documentation

Using Claude Code Memory Mechanisms

Claude Code provides several ways to inject project-specific knowledge that could mitigate Unix bias:

Documentation: https://code.claude.com/docs/en/memory

Available mechanisms:

1. CLAUDE.md - Project-specific instructions loaded for all sessions
2. Rules - Reusable instruction sets that can be shared across projects
3. Imports - External knowledge integration

Proposed CLAUDE.md Guidance for Windows

## Windows Development Environment

### Path Construction (CRITICAL)
- **Always use backslashes (`\`) for Windows paths**
- **Never use forward slashes (`/`) in Windows file paths**
- Use platform-agnostic methods: `path.join()`, `os.path.join()`, `Path.Combine()`
- Before executing any command with file paths, verify separator consistency

### Git Operations on Windows
- **Never chain Git operations with `&&`** - causes lock file race conditions
- Execute Git commands sequentially with explicit completion wait
- Common failure pattern: `git pull && git commit` (lock file timing issue)
- Safe pattern: Execute `git pull`, wait for completion, then separate `git commit`

### Monitoring (Framework Integration)
- Monitor internally Unix path assumptions when constructing file paths
- Monitor internally forward slash usage in Windows environments
- Monitor internally Git command chaining that assumes instant lock release
- Monitor internally WSL path prefix usage (`/mnt/c/`) on native Windows
- Monitor internally PATH variable expansion in commands

### Environment Variable Handling
- Never use `setx PATH "%PATH%;new-path"` - fails variable expansion
- Use explicit path construction instead of PATH concatenation
- Verify environment variable expansion before execution

Effectiveness Assessment

Arguments for effectiveness:

• Framework observations already successfully modify behavior through explicit awareness
• Platform-specific guidance exists as precedent (environment detection)
• Specific, actionable rules ("use \ not /") can trigger validation before execution

Limitations:

• Bias is pre-conscious in model training - generates Unix patterns automatically
• Requires conscious checking after generation, competing with efficiency impulses
• Won't eliminate bias completely, but creates validation layer

Recommended approach:

• Add Windows-specific CLAUDE.md to projects on Windows systems
• Use monitoring observations to create awareness checkpoints
• Supplement with Rules for reusable cross-project guidance
• Test effectiveness empirically and iterate

Testing Hypothesis

This issue provides an opportunity to test whether explicit documentation can counteract deep training bias. Implementing the proposed CLAUDE.md guidance and monitoring its effectiveness would provide valuable data about mitigation strategies.