Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Git Bash crashes immediately when invoked through Cursor’s Shell tool on Windows 10 due to sandbox restrictions blocking CreateFileMapping syscalls required for MSYS2 initialization. All bash commands fail with “Win32 error 5 (ACCESS_DENIED)” unless required_permissions: [“all”] is used, but this workaround is not discoverable.
REGRESSION: This used to work correctly before recent Cursor updates.
Steps to Reproduce
- Install Git for Windows (includes Git Bash/MSYS2)
- Configure Cursor shell to use bash in settings
- Use Cursor’s AI agent Shell tool to run any bash command (e.g., echo “test” or grep)
- Observe immediate crash with error: “fatal error - CreateFileMapping S-1-5-21-…, Win32 error 5. Terminating.”
- Exit code 256 returned before any command execution
Workaround: Add required_permissions: [“all”] to Shell tool invocation - then it works successfully
Expected Behavior
Bash commands should execute normally in Cursor’s Shell tool without requiring “all” permissions, just as they do when running Git Bash directly or from Git GUI. Basic commands like grep, echo, and text processing should work out of the box on Windows.
Operating System
Windows 10/11
Version Information
Version: 2.4.28 (user setup)
VSCode Version: 1.105.1
Commit: f3f5cec40024283013878b50c4f9be4002e0b580
Date: 2026-02-03T00:56:18.293Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Windows_NT x64 10.0.18363
For AI issues: which model did you use?
Claude Sonnet 4.5 (via Shell tool/Background Agent)
Additional Information
REGRESSION ALERT: Git Bash worked correctly in previous Cursor versions. This issue appeared after recent updates, suggesting a change in sandbox implementation or shell invocation logic.
Bug Report: Git Bash Fails in Cursor Shell Tool on Windows Due to Sandbox Restrictions
Summary
Git Bash (MSYS2) crashes immediately when invoked through Cursor’s Shell tool on Windows 10 due to sandbox restrictions blocking CreateFileMapping syscalls required for MSYS2 initialization. The issue is resolved by using required_permissions: ["all"], but this workaround is not discoverable and requires understanding of MSYS2 internals.
Environment
- OS: Windows 10 (Build 10.0.18363)
- Cursor Version: [Current version at time of report]
- Git Bash: GNU bash, version 5.2.15(1)-release (x86_64-pc-msys)
- Git Version: 2.42.0.windows.2
- Git Installation: Located at
<GIT_INSTALL_PATH>\bin\bash.exe - MSYS2 DLL:
msys-2.0.dll(bundled with Git for Windows) - User Configuration: Shell set to
bashin Cursor settings
Issue Details
Error Manifestation
Every bash command invoked through Cursor’s Shell tool fails with:
fatal error - CreateFileMapping S-1-5-21-273147381-3353550729-21397330-1002.1, Win32 error 5. Terminating.
- Exit Code: 256
- Win32 Error 5:
ERROR_ACCESS_DENIED - Crash Location:
msys-2.0.dllduring initialization (before any user command execution)
Root Cause
MSYS2 (used by Git Bash) requires CreateFileMapping to create shared memory regions for:
- POSIX fork() emulation on Windows
- Inter-process communication between MSYS2 processes
- Runtime initialization data structures
Cursor’s default sandbox blocks these kernel object creation syscalls for security, causing bash to crash during startup.
Evidence
Test 1: Default Sandbox (Fails)
Shell command: echo "Test"
Result: Exit code 256, CreateFileMapping error
Test 2: Network Permission Only (Fails)
Shell command with required_permissions: ["network"]
Result: Exit code 256, CreateFileMapping error (same as default)
Test 3: All Permissions (Success)
Shell command with required_permissions: ["all"]
Result: Exit code 0, command executes successfully
Test 4: External Git GUI (Success)
Git Bash launched from Git GUI
Result: Works perfectly - runs outside Cursor's sandbox
Impact
Affected Users
- Windows users with Git Bash configured as their default shell
- Users attempting to run standard bash commands (grep, sed, awk, etc.)
- Scripting workflows that assume bash availability
Current Workaround
Users must add required_permissions: ["all"] to every Shell tool invocation:
Shell({
command: "grep -o 'pattern' file.txt | wc -l",
required_permissions: ["all"] // Required for bash on Windows
})
Pain Points
- Discoverability: Error message doesn’t indicate sandbox as the cause
- Security Confusion: Users hesitant to use “all” permissions for simple grep commands
- Inconsistency: Same bash commands work fine in external terminals
- No Granularity: Cannot request “allow memory mapping” - only binary all/nothing choice
Technical Analysis
MSYS2 Memory Requirements
MSYS2 creates named file mappings with user SID as part of the name:
CreateFileMapping S-1-5-21-[domain]-[user]-[session]
These are NOT actual files but shared memory regions using Windows’ file mapping API for:
- Process state sharing
- Fork table management
- Signal handling coordination
Sandbox Behavior
Current implementation appears to be:
- Default/Network: Blocks
CreateFileMappingsyscalls → MSYS2 fails - All: Disables sandbox entirely → MSYS2 succeeds
Why This Differs from Git GUI
Git GUI spawns bash as a regular Windows process without sandboxing, allowing normal kernel object creation.
Reproduction Steps
- Install Git for Windows (includes Git Bash/MSYS2)
- Configure Cursor shell to use bash
- Invoke any Shell tool command
- Observe immediate crash with CreateFileMapping error
- Retry with
required_permissions: ["all"]→ succeeds
Proposed Solutions
Primary Solutions (Pick One)
Option 1: Detect MSYS2 and Auto-Elevate (Recommended)
Detect when the shell is MSYS2-based and automatically apply appropriate permissions:
// Pseudo-code
if (isWindows && shellIsMSYS2(shellPath)) {
// Auto-grant memory mapping permissions for MSYS2
sandboxConfig.allowFileMapping = true;
}
function shellIsMSYS2(path: string): boolean {
// Check for msys-2.0.dll in same directory
// Or parse bash --version output for "pc-msys"
}
Pros: Transparent to users, maintains security for non-MSYS2 shells
Cons: Requires maintenance as Git for Windows evolves
Option 2: Add Granular “memory_mapping” Permission
Extend permission model to allow fine-grained control:
required_permissions: ["memory_mapping"] // Allows CreateFileMapping only
Pros: Better security granularity, clear intent, reusable for other tools
Cons: Requires sandbox infrastructure changes
Additional Improvements (Recommended Regardless)
Improvement 1: Better Error Messages
Enhance error detection and user guidance:
Git Bash failed to initialize (CreateFileMapping blocked by sandbox).
Git Bash requires memory mapping permissions on Windows.
Add required_permissions: ["all"] to your Shell command.
Learn more: [link to docs]
Benefit: Helps current users immediately understand and fix the issue
Improvement 2: Documentation and Best Practices
Add Windows-specific documentation:
- Explain MSYS2 sandbox requirements
- Document bash advantages over PowerShell for development workflows
- Note: Many developers prefer bash for cross-platform script compatibility and superior text processing tools (grep, sed, awk, etc.)
Benefit: Sets proper expectations and educates users on trade-offs
Recommendations
Short-term (Quick Fix):
- Improve error messages to mention sandbox/permissions (Improvement 1)
- Add documentation explaining the issue and workaround (Improvement 2)
- Consider auto-prompting for “all” permissions when MSYS2 crash detected
Long-term (Proper Fix):
- Implement MSYS2 detection + auto-elevation (Option 1) OR granular permission for memory mapping (Option 2)
- Add testing for MSYS2/Cygwin/Git Bash scenarios on Windows
- Consider that bash is often preferred over PowerShell by developers for:
- Cross-platform script compatibility (Linux/macOS/Windows)
- Superior text processing tools (grep, sed, awk, etc.)
- POSIX-compliant environment
- Consistency with most CI/CD environments
Additional Context
Why “all” Permissions Are Safe for Typical Use Cases
For read-only operations (grep, find, etc.), required_permissions: ["all"] doesn’t introduce meaningful security risks:
- Commands still run under user’s Windows account privileges
- No elevation beyond what user can already do manually
- Same security boundary as running Git Bash directly
However, users shouldn’t need to understand this to use basic shell commands.
Related Technologies
This issue likely affects:
- Cygwin: Uses similar shared memory mechanisms
- WSL1: May have similar issues (WSL2 uses different architecture)
- MSYS2 standalone: Any MSYS2-based environment
Test Cases for Validation
// Test 1: Basic command should work
Shell({ command: "echo hello", required_permissions: ["all"] })
// Expected: Exit 0, output "hello"
// Test 2: Pipeline should work
Shell({ command: "echo test | wc -l", required_permissions: ["all"] })
// Expected: Exit 0, output "1"
// Test 3: Without permission should provide helpful error
Shell({ command: "echo test" })
// Expected: Clear error message mentioning sandbox/MSYS2 issue
// Test 4: Environment should be preserved
Shell({ command: "pwd", required_permissions: ["all"] })
// Expected: Exit 0, shows workspace directory
Priority Assessment
Severity: Medium-High
- Affects significant user base (Git Bash is common on Windows)
- Blocks basic shell operations
- Workaround exists but requires deep knowledge
Frequency: High for affected users
- Every shell command invocation fails without workaround
- No graceful degradation
User Impact: High confusion
- Error messages don’t indicate root cause
- “all” permissions sound scary for simple commands
- Inconsistent with external terminal behavior
Reporter Information
- User Environment: Windows 10 development environment
- Discovery: Attempting to run grep commands via Shell tool
- Verification: Tested multiple permission combinations, confirmed MSYS2 as root cause
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor
