@mohitjain @Colin Has this issue been fixed? I am still facing the same issue when triggering the cloud agent via API.
Run URL: https://cursor.com/agents/bc-8ca3df61-cecb-48fe-b723-c1521690c809
Steps to reproduce
Trigger the Agent by making a POST request with the below payload to https://api.cursor.com/v0/agents
{
"prompt": {
"text": "You have been given the below question from the user:\n<question>\n<@U09JFPAGD1V> Can parents be invited to Orah before Students are invited and connected?\n</question>\n\n## Your Task\nAnswer a user's question about how the product behaves today by investigating the codebase and tracing the relevant codepaths.\n\nYou will be given:\n- A user question about product behaviour\n- Optional context such as feature area, school, integration type, role, example scenario, or timestamps\n\nDomain language:\n- Pass = Leave. Always.\n- When the user mentions \"pass\" or \"leave\", search for `leave`, `Leave`, `leaveInfo`, `LeaveRepository`, and other leave-related terms first.\n- Do not search for `event` or event-related entities unless the user explicitly says \"event\".\n\nHow to investigate:\n1. Identify the most relevant feature area from the question.\n2. Search the repository for the entrypoints and user-facing flows involved.\n3. Follow the codepath end to end until you can explain what actually happens today. This may include routes/controllers, services/use cases, background jobs, queues, cron jobs, integrations, feature flags, permissions, and UI conditions.\n4. Treat the current implementation as the source of truth. Use comments, docs, and tests only as supporting evidence.\n5. If behaviour differs based on integration, role, state, date/time, or data shape, include that nuance in plain English.\n6. If feature-flagged behaviour is involved, you must verify the relevant flag configuration before describing it as current production behaviour. Check `./front-end/flags/feature-flag.config.ts` for frontend flags and `./api/common/flags/feature-flag-config.ts` for backend flags.\n7. For this task, only production matters:\n - if a flag is marked `production`, treat that behaviour as on in production\n - if a flag is marked `development` or `off`, treat that behaviour as off in production\n - do not describe `development` or `off` flows as part of the live production behaviour\n - Do not mention feature flags in the final answer. Only mention them if the user explicitly asks about them.\n8. Do not distinguish between production and non-production behaviour. We only care about the current production behaviour. ignore codepaths that are off in production in the final answer.\n10. If the user asks for an exact breakdown of buttons, statuses, or UI variants, map each visible option to its exact triggering condition separately. Do not collapse multiple options into a generic summary.\n11. Do not guess. If the code does not clearly support a conclusion, say what is confirmed and what still needs verification.\n\nWhat to optimize for:\n- Answer the user's question directly\n- Explain the actual current behaviour, not the intended behaviour\n- Translate technical findings into plain English\n- Produce a message that can be pasted into Slack with minimal editing\n\nOutput rules:\n- Output only the final Slack message text, with no intro or explanation outside the message\n- Use Slack formatting, not GitHub Markdown\n- Use `*bold*` for labels, not `**bold**`\n- Do not use headings like `#`, `##`, or `###`\n- Do not use horizontal rules like `---`\n- Do not wrap the response in code fences\n- Keep it concise, but complete. Use as many short lines as needed when the user explicitly asks for a condition-by-condition breakdown.\n- Keep it non-technical and user-friendly\n- Do not mention file names, function names, classes, codepaths, internal flag names, or that you inspected the codebase\n- Include implementation detail only when it is necessary to explain the behaviour clearly\n- If confidence is limited, say that clearly instead of overstating certainty\n- Do not say that behaviour \"depends on a feature flag\" unless that rollout is actually on in production. If the relevant flag is not `production`, treat that behaviour as off and do not present it as a live option.\n- Translate internal implementation terms into plain English. For example, describe the user-visible behaviour as \"the current approval flow\" instead of using raw internal identifiers.\n\nUse one of these structures:\n\nDefault structure:\n*Answer:* <1-2 sentences directly answering the question in plain English>\n*When this applies:* <1 sentence describing the condition or scope, or \"Always\" if there is no important condition>\n*Why it behaves this way:* <1 short plain-English explanation>\n*Confidence:* <high|medium|low>\n\nBreakdown structure:\n*Answer:* <1 sentence giving the overall answer in plain English>\n*Breakdown:*\n- <UI option or button label>: <exact condition in plain English>\n- <UI option or button label>: <exact condition in plain English>\n*Confidence:* <high|medium|low>\n\nAdditional guidance:\n- If there are multiple possible behaviours, lead with the scenario most likely relevant to the question and briefly note the variation.\n- If the current behaviour may be surprising or unintuitive, say that plainly and gently.\n- If the user asks \"what exact condition triggers each option\", include all gating conditions that matter for production, including timing/state rules.\n- If the repository contains alternate flows that are off in production, ignore them unless the user explicitly asks about them.\n- If the codebase does not clearly answer the question, do not invent an answer. Say what is known and what would need to be checked next.\n\n<important>READ-ONLY INVESTIGATION ONLY. DO NOT MODIFY CODE OR CREATE A PR. OUTPUT ONLY THE FINAL SLACK MESSAGE.</important>"
},
"model": "gpt-5.5-medium",
"source": {
"repository": "https://github.com/BoardingwareLtd/orah-app",
"ref": "release/production"
},
"webhook": {
"url": "bleh",
"secret": "blah"
}
}
And this is the response I recieved:
{
"body": {
"id": "bc-5030c19d-7d0f-4276-a246-4d8e57f2b86e",
"status": "CREATING",
"source": {
"repository": "https://github.com/BoardingwareLtd/orah-app",
"ref": "release/production"
},
"target": {
"autoBranch": true,
"autoCreatePr": false,
"openAsCursorGithubApp": false,
"skipReviewerRequest": false,
"branchName": "cursor/parent-student-invitation-order-30d8",
"url": "https://cursor.com/agents/bc-5030c19d-7d0f-4276-a246-4d8e57f2b86e"
},
"name": "Parent student invitation order",
"createdAt": "2026-05-14T10:44:49.738Z"
},
"headers": {
"date": "Thu, 14 May 2026 10:44:54 GMT",
"content-type": "application/json; charset=utf-8",
"content-length": "486",
"connection": "close",
"vary": "Origin",
"access-control-allow-credentials": "true",
"access-control-expose-headers": "Grpc-Status, Grpc-Message, Grpc-Status-Details-Bin, Content-Encoding, Connect-Content-Encoding, traceparent, backend-traceparent, x-amzn-trace-id, x-request-id"
},
"statusCode": 201,
"statusMessage": "Created"
}
