Component
Plugin
Description
Summary
The Cursor plugin's sessionStart implementation unnecessarily increases the chance of losing the initial Mem0 context due to a known Cursor race condition.
Cursor has already confirmed that sessionStart runs asynchronously and additional_context may be silently dropped if the initial composer/request is created first:
Mem0 currently waits for the entire [on_session_start.sh](https://github.com/mem0ai/mem0/blob/main/integrations/mem0-plugin/scripts/on_session_start.sh) before returning anything to Cursor:
TEXT=$("$SCRIPT_DIR/on_session_start.sh" 2>/dev/null || echo "")
jq -cn --arg ctx "$TEXT" '{additional_context:$ctx}'
See [on_session_start_cursor.sh](https://github.com/mem0ai/mem0/blob/main/integrations/mem0-plugin/scripts/on_session_start_cursor.sh).
Steps to Reproduce
- Install the official Mem0 Cursor plugin.
- Start a new agent session and immediately submit the first prompt.
- Repeat several times, especially with non-trivial Mem0 API latency.
on_session_start.sh synchronously performs several operations before it exits, including a Mem0 API request for memory count:
urllib.request.urlopen(req, timeout=5)
and session timeline generation with another timeout:
perl -e 'alarm 5; exec @ARGV' python3 "$SCRIPT_DIR/session_timeline.py"
Only after all of this completes can on_session_start_cursor.sh return additional_context.
Expected Behavior
The essential session context, especially:
Mem0 Active | user=... | project=... | branch=...
should reach the first agent turn reliably.
Actual Behavior
The hook can successfully generate the context, but the first response occasionally behaves as if it was never injected.
This is consistent with Cursor's confirmed sessionStart race condition. Mem0's synchronous network/enrichment work makes the timing window substantially larger.
A simple mitigation would be to keep the critical path local: resolve user, project, and branch, immediately return additional_context, and move memory count, timeline generation, auto-import, telemetry, etc. to background work.
Related Cursor reports:
Environment
- mem0 version: latest v2.0.17
- Cursor: 3.14.27
- OS: Linux
Component
Plugin
Description
Summary
The Cursor plugin's
sessionStartimplementation unnecessarily increases the chance of losing the initial Mem0 context due to a known Cursor race condition.Cursor has already confirmed that
sessionStartruns asynchronously andadditional_contextmay be silently dropped if the initial composer/request is created first:Mem0 currently waits for the entire
[on_session_start.sh](https://github.com/mem0ai/mem0/blob/main/integrations/mem0-plugin/scripts/on_session_start.sh)before returning anything to Cursor:See
[on_session_start_cursor.sh](https://github.com/mem0ai/mem0/blob/main/integrations/mem0-plugin/scripts/on_session_start_cursor.sh).Steps to Reproduce
on_session_start.shsynchronously performs several operations before it exits, including a Mem0 API request for memory count:and session timeline generation with another timeout:
Only after all of this completes can
on_session_start_cursor.shreturnadditional_context.Expected Behavior
The essential session context, especially:
should reach the first agent turn reliably.
Actual Behavior
The hook can successfully generate the context, but the first response occasionally behaves as if it was never injected.
This is consistent with Cursor's confirmed
sessionStartrace condition. Mem0's synchronous network/enrichment work makes the timing window substantially larger.A simple mitigation would be to keep the critical path local: resolve
user,project, andbranch, immediately returnadditional_context, and move memory count, timeline generation, auto-import, telemetry, etc. to background work.Related Cursor reports:
Environment