@cursor/[email protected]: sessionStart runs, but additional_context never reaches the model

Where does the bug appear (feature/product)?

Cursor SDK

Describe the Bug

Originally observed on 1.0.23 and reproduced on 1.0.28. The sessionStart hook executes and returns additional_context, but the marker is not available to the model on the first turn.

A project-level sessionStart hook returns additional_context that should be added to the model’s initial context.

This works in the Cursor IDE. When the same project is executed using Agent.create with the local runtime, the hook runs successfully, but its additional_context never reaches the model.

Hook logs, sidecar output, and the presence of session_id in the hook environment confirm that execution succeeds. The failure is specifically in propagating the returned context into the model request.

Steps to Reproduce

  1. Configure a project-level sessionStart hook that returns additional_context containing a unique marker.
  2. Open the project in the Cursor IDE and start a new session.
  3. Ask the model on the first turn, without using tools, to repeat the marker. The model can identify it.
  4. Run the same project using Agent.create with the local runtime.
  5. Confirm through the hook logs that sessionStart executed and returned the context.
  6. Ask the model the same question on the first turn, without using tools.

The model behaves as though the returned context was never added to the session.

Expected Behavior

The additional_context returned by sessionStart should be included in the model’s initial context before the first user message is processed, matching the behavior of the Cursor IDE.

Operating System

MacOS

Version Information

@cursor/sdk: 1.0.28
Runtime: local
API: Agent.create

Additional Information

The hooks adapter already maps the hook result to { additionalContext }, and the request-context implementation awaits hooksAdditionalContextPromise before assigning the result to RequestContext.hooksAdditionalContext.

However, wrapResources constructs the request-context wrapper with hooksAdditionalContextPromise set to undefined. This appears to leave the result of onSessionStart disconnected from the request context consumed by the model.

Proposed fix:

  1. Create a deferred promise in the resource-wrapper factory.
  2. Pass that promise to the request-context accessor.
  3. Resolve it with additional_context when onSessionStart completes.
  4. Resolve it with undefined if the hook is skipped or throws, preventing the request from remaining blocked.

The context should be propagated through RequestContext.hooksAdditionalContext, not prepended to the user prompt.

A temporary workaround for @cursor/[email protected] is available at GitHub - jgabriellima/cursor-sdk-session-start-patch: @cursor/[email protected] workaround: sessionStart runs, additional_context never reaches the model · GitHub

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Thanks for the detailed report. I confirmed the behavior you described with Agent.create using the local runtime. The sessionStart hook can run successfully, even if its returned additional_context remains unavailable during the first model turn. This is not caused by your configuration, and we’ve let the team know.

One note on the linked workaround: its current apply.mjs only includes support for @cursor/sdk 1.0.23. With 1.0.28 it returns skipped-no-recipe, despite the README mentioning 1.0.28.

For static context, an always-applied Project Rule or AGENTS.md may provide a temporary alternative: Rules | Cursor Docs . For dynamic context, passing the value in the first SDK prompt can unblock the run, although it is not equivalent to the initial system context.

I don’t have a supported system-context-equivalent workaround to share right now, but I’ll update this thread when there is something concrete.

Hi Kevin,

Thank you for the follow-up and for confirming the behavior with Agent.create. I will look forward to any updates regarding the fix from the team.

Best regards,