Baike.dev
Log in
Back to tool/Back to issues
#7342·mem0

Windows: Cursor plugin 0.2.13 spawns hung Git Bash (mintty) windows on Read hooks

Author: BrianThomasFDCCreated Sep 15, 2026Updated Sep 16, 2026
Labelsbugsdk-python

Component

Python SDK

Description

Summary

On Windows, mem0 Cursor plugin 0.2.13 runs agent hooks as .sh scripts. Git for Windows launches those via git-bash.exe, which opens a focus-stealing mintty Git Bash window. A preToolUse hook matching Read (on_file_read_cursor.sh) therefore opens a visible window on every file an agent reads. Those windows do not exit. Disabling the plugin and restarting Cursor stops them.

This is not #6252 (auto_search on the same script). GitHub code search on mem0ai/mem0 does not currently return on_file_read_cursor.sh; the files below are from the installed Cursor marketplace plugin cache (plugin.json "repository": "https://github.com/mem0ai/mem0").

The Python SDK snippet in this form does not apply. Reproduction is a Cursor plugin hook on Windows, not from mem0 import Memory.

Steps to Reproduce

# Not applicable — this is not the Python SDK.
# from mem0 import Memory
# m = Memory()

# Repro (Windows + Cursor plugin):
# 1. Git for Windows installed (C:\Program Files\Git\git-bash.exe present).
# 2. Enable mem0 Cursor plugin 0.2.13.
# 3. In Cursor, run agent activity that reads files (preToolUse matcher "Read").
# 4. Git Bash (mintty) windows appear; command lines target
#    ...\mem0\...\scripts\on_file_read_cursor.sh
#    launched as: git-bash.exe → mintty → bash --login -i <script>
# 5. Disable mem0, fully restart Cursor, repeat step 3 → no Git Bash windows.

Hook registration (hooks/cursor-hooks.json in plugin 0.2.13):

{
  "command": "${CURSOR_PLUGIN_ROOT}/scripts/on_file_read_cursor.sh",
  "matcher": "Read",
  "timeout": 5
}

scripts/on_file_read_cursor.sh begins:

#!/usr/bin/env bash
set -uo pipefail

INPUT=$(cat)

Expected Behavior

Hook scripts run headless: no Git Bash/mintty window. Stdin is the hook JSON pipe. The process exits after the hook finishes (or after timeout, with no leftover UI).

Actual Behavior

Visible Git Bash windows appear on Read (four mintty windows in ~3 seconds in the capture, all on_file_read_cursor.sh). They stay open. Closing them reports a process still running. The hook timeout of 5 did not reap the windows.

Captured mintty command line (parent process: git-bash.exe):

usr\bin\mintty.exe --nodaemon -o AppID=GitForWindows.Bash -o AppLaunchCmd="C:\Program Files\Git\git-bash.exe" -o AppName="Git Bash" -i "C:\Program Files\Git\git-bash.exe" --store-taskbar-properties -- /usr/bin/bash --login -i "C:\Users\brian.thomas\.cursor\plugins\cache\cursor-public\mem0\965140eb190bf390979d41bb6ffff12c0b02e70b\scripts\on_file_read_cursor.sh"

Environment

  • mem0 version: Cursor plugin 0.2.13 (marketplace cache hash 965140eb190bf390979d41bb6ffff12c0b02e70b)
  • Python/Node version: not applicable (hook is bash, not the Python/TS SDK)
  • OS: Windows
  • Also: Cursor IDE; Git for Windows (git-bash.exe, usr\bin\bash.exe)

How You Verified This

What I Ran

PowerShell process watcher on the Windows machine (polled Win32_Process for mintty.exe / bash.exe / sh.exe every 2s, printed pid, parent name, and CommandLine).

Then, in Cursor with mem0 enabled: agent activity that reads files (including a test commit / file reads around 12:18–12:19 local time).

Then: disable mem0 in Cursor Customize, restart Cursor, repeat agent file-read activity.

Also inspected the installed plugin: hooks/cursor-hooks.json and scripts/on_file_read_cursor.sh under:

C:\Users\brian.thomas\.cursor\plugins\cache\cursor-public\mem0\965140eb190bf390979d41bb6ffff12c0b02e70b\

What I Saw

12:18:58  NEW mintty.exe  pid 27424  parent: git-bash.exe
     cmd: usr\bin\mintty.exe --nodaemon -o AppID=GitForWindows.Bash -o AppLaunchCmd="C:\Program Files\Git\git-bash.exe" -o AppName="Git Bash" -i "C:\Program Files\Git\git-bash.exe" --store-taskbar-properties -- /usr/bin/bash --login -i "C:\Users\brian.thomas\.cursor\plugins\cache\cursor-public\mem0\965140eb190bf390979d41bb6ffff12c0b02e70b\scripts\on_file_read_cursor.sh"
12:18:59  NEW mintty.exe  pid 50308  parent: git-bash.exe
     cmd: usr\bin\mintty.exe --nodaemon ... -- /usr/bin/bash --login -i "...\scripts\on_file_read_cursor.sh"
12:19:00  NEW mintty.exe  pid 42048  parent: git-bash.exe
     cmd: usr\bin\mintty.exe --nodaemon ... -- /usr/bin/bash --login -i "...\scripts\on_file_read_cursor.sh"
12:19:00  NEW mintty.exe  pid 59696  parent: git-bash.exe
     cmd: usr\bin\mintty.exe --nodaemon ... -- /usr/bin/bash --login -i "...\scripts\on_file_read_cursor.sh"

Also in the same burst:

12:18:41  NEW bash.exe  pid 47408  parent:
     cmd: "C:\Program Files\Git\\\usr\bin\bash.exe" --login -i C:\Users\brian.thomas\.cursor\plugins\cache\cursor-public\mem0\965140eb190bf390979d41bb6ffff12c0b02e70b\scripts\on_user_prompt_cursor.sh

After disabling mem0 and restarting Cursor: no new Git Bash/mintty windows under the same kind of agent file reads.

No Python traceback: this is not from mem0 import Memory.

Why This Is a Bug

Hooks should run without a GUI console. The plugin itself declares a 5-second timeout on this hook, which implies a short-lived, non-interactive command — not an interactive Git Bash window that outlives the timeout.

What says so in the plugin code:

  • hooks/cursor-hooks.json binds on_file_read_cursor.sh to preToolUse matcher Read (fires on every agent file read).
  • on_file_read_cursor.sh is meant to consume hook JSON from stdin (INPUT=$(cat)), then optionally emit hook output JSON.

Observed vs that contract: Windows launches git-bash.exe (mintty launcher) with bash --login -i <script>. That is Git for Windows' windowed login shell, not a piped bash.exe -c job.

Inferred, not instrumented: leftover windows stay up because stdin is a TTY, so INPUT=$(cat) never sees EOF. Not confirmed with test -t 0 or a debugger.

What I Ruled Out

  • Cursor user settings.json terminal profiles (terminal.integrated.profiles.windows, defaultProfile, confirmOnKill, enablePersistentSessions). User settings had no Git Bash profile; persistentSessionReviveProcess: "never" did not stop the windows while mem0 was enabled.
  • Cursor integrated terminal tabs / Terminal: Kill All Terminals (these were standalone mintty windows, parent git-bash.exe).
  • Cursor git core.hooksPath / ~/.cursor/agent-hooks. Watcher command lines named mem0 plugin scripts, not agent-hooks.
  • VS Code %APPDATA%\Code\User\settings.json (separate app; does not govern Cursor).
  • mem0 Python SDK, TypeScript SDK, vector store, REST API (no Memory() call in the repro).
  • Claude Code (claude.exe in the same log uses Git\bin\bash.exe -c with no mintty); those lines are a different product.
  • astronomer-data airflow-skill-suggester.sh appeared once as bash.exe --login -i; the mintty burst was exclusively mem0 on_file_read_cursor.sh. Disabling mem0 alone stopped the window flood.

AI Assistance

AI helped me find it, and I reproduced it myself afterwards

Source: mem0ai/mem0

View original on GitHubView discussion on GitHub