Cursor Live Task Allow List does not include Grok 4.7

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When running an agent as Grok 4.7 Extra High, child workers cannot be spawned as Grok 4.7 because they are not in the “Live Task Allow List”

From the model’s own diagnostic of this problem:
This chat’s picker is already Grok 4.7, reasoning xhigh, Fast off. The CLI id for that variant is grok-4.7-xhigh. The live Task allowlist is still:

composer-2.5-fast
cursor-grok-4.6-high-fast
gemini-3.6-flash-high
gpt-5.6-sol-low
Probe Result
Model omitted
Auto
Legacy slug grok-4.7-xhigh
Auto
Frontmatter grok-4.7-xhigh
Composer
Allowlisted cursor-grok-4.6-high-fast
Cursor Grok 4.6
The exact parameter form grok-4.7[context=256k,reasoning_effort=xhigh,fast=false] was rejected with the same four-slug list. A custom subagent type was rejected because Task only accepts the built-in types. Changing the saved enabled-model list from grok-4.6 to grok-4.7 did not refresh that list, so I restored the original list.

Steps to Reproduce

Try to run a subagent/worker from within an agent call using Grok 4.7, and have the caller/orchestrator agent check which model actually got called - defaults back to composer.

Expected Behavior

Grok 4.7 should call Grok 4.7 workers.

Operating System

Windows 10/11

Version Information

Version: 3.21.16 (system setup)
VS Code Extension API: 1.128.0
Commit: 8ae78e8eee1e63479c7e0504b664bc0a80c68000
Date: 2026-09-19T06:43:22.276Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.19045

Does this stop you from using Cursor

Yes - Cursor is unusable

6

Currently using a custom MCP server to run Cursor CLI workers at any thinking level I want. It’s a hack, and I have to tell the agent to wait for the responses, otherwise it ends the turn. Would love for this to be resolved.

8

Hey @Zachariah, To get real Grok 4.7 workers today, delegate from a Cloud Agent - its subagents can be pinned to Grok 4.7 at any effort level (locally the Task list only exposes the Grok 4.6 entry, which is why editing your enabled models didn’t help). This isn’t anything on your end, and it’s an issue we’re tracking - I’ll post back here when there’s an update.

10

Thank you.
This project uses only a local repo (mostly due to how the database dev work is currently setup) making Cloud workers a no-go for this project at this time. I’ll keep using my hack for now. Thank you for tracking the issue and replying back when it’s solved!

12

Hey @Zachariah,

Following up as promised. This has been addressed on our side and will be rolled out soon if it hasn’t been already. No Cursor update is needed.

Subagents launched from a local Grok 4.7 agent (including ones that inherit the parent’s model) should now run on Grok 4.7 instead of silently falling back to Auto.

Could you give it another try with a local Grok 4.7 agent and let me know if the workers still end up on Auto? If you pin a specific reasoning level for a worker and it doesn’t stick, let me know here too.