Repository navigation
[Bug]: Grok provider: skills/slash commands empty; ACP crash on skills-reload (BigInt RequestId) #4109
Description
Activity
- addedbugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.
on Jul 17, 2026 I can reproduce the same ACP failure on Windows, so this is not limited to macOS.
Environment:
- Windows 11 24H2 build 26100.8875, AMD64
- T3 Code Alpha 0.0.28
- Grok CLI 0.2.106
An earlier
server-child.logentry showed the same failure duringcheckGrokProviderStatus:SyntaxError: Cannot convert skills-reload to a BigInt at BigInt (<anonymous>) at effect-acp/AcpClient.make at checkGrokProviderStatusWith Grok 0.2.106, the current provider result is:
Grok CLI is installed but ACP startup timed out after 15000ms.The CLI itself is healthy and authenticated outside T3:
grok 0.2.106 grok models You are logged in with grok.com. Default model: grok-4.5This rules out a missing binary or login problem and points to the ACP handshake/request-ID path. One additional Windows-specific risk is that both Cursor and Grok installations may expose an executable named
agent.exe; provider startup should resolve an explicit provider-specific binary rather than whichever genericagentappears first on PATH.Opened a fix for this: #5131
Grok already sends skills and slash commands over ACP (
available_commands_update). OpenCode already exposes the same kind of list on the SDK (/command,/skill). T3 never copied either catalog into provider status, so/and$stayed empty even when the CLIs were healthy.On Grok the PR captures that ACP catalog during provider status startup and feeds the pickers. On OpenCode it loads from those SDK endpoints.
I reproduced empty pickers on current
mainin a local clone, then saw them fill on the fix branch with real Grok and OpenCode installs.The older
skills-reload/BigIntcrash looks unrelated. Grok still emitsid: "skills-reload", but Effect no longer BigInt-coerces string request ids, and that change is already on main.Still reproduces on macOS desktop Alpha with Grok:
~/.t3/caches/grok.jsonhas"skills": []/"slashCommands": []while skills exist under~/.grok/skills. Watching #5131.Still reproduces on macOS desktop Alpha with Grok:
~/.t3/caches/grok.jsonhas"skills": []/"slashCommands": []while skills exist under~/.grok/skills. Watching #5131.I reproduced the empty
$picker with Grok and opened PR #5960 with a narrower filesystem-based fix.Grok loads skills from these locations:
~/.agents/skills~/.grok/skills<project>/.agents/skills<project>/.grok/skills
T3's Grok provider snapshot currently doesn't scan those roots, so its
skillsarray remains empty even when Grok can use the skills directly.The PR extracts Claude's existing
SKILL.mdscanner into a shared helper and uses it for Grok. Project roots override user roots on name collisions. Skills are retained on usable Grok snapshots even if ACP model discovery fails.This intentionally addresses only filesystem skills in the
$picker. It does not address slash commands, Grok's config-basedpaths/disabledbehavior, or the olderskills-reloadACP failure.This differs from #5131, which consumes Grok's ACP command catalog. The filesystem scan provides paths, scopes, deterministic root precedence, and remains available when ACP catalog discovery fails.
still not fixed :C
Hey! I opened #7919 to fix the missing Grok skills reported here.
The problem was that T3 never asked Grok for its resolved skill catalog. The PR now uses
grok inspect --json, so user, project, bundled, and plugin skills appear in the$picker and as skill entries under/.I tested it on Windows with Grok CLI 1.0.5, where it found 49 skills, and added focused coverage for the failure cases. If
inspectfails or times out, T3 simply keeps working without skills instead of marking Grok as unhealthy.One scope note: this fixes the missing skills, but it doesn’t change ACP request-ID handling or add Grok’s general slash commands.
There are before-and-after screenshots in the PR. Feedback from anyone using Grok on macOS or Linux would be especially helpful!
I tried to fix it but my PR got rejected by his GPT bot saying the code touched a vouched PR in progress. So there went that. I ended up forking and making a custom actions workflow to auto-patch each update so it feels like I am on the nightly+my patch with no effort. I'm happy at least it works for me but it's a shame they auto rejected the pr for everybody else.
Reacted by Harshit Pantthey put way to much energy on Mac OS and C.GPT + Claude models; else is just sideline things. This same issue of skills not being recognised is happening in OpenCode as well.
Reacted by FenrisHonestly it was a very easy fix. Took like 15 min to do. Kind of ridiculous lol.
I tried to fix it but my PR got rejected by his GPT bot saying the code touched a vouched PR in progress. So there went that. I ended up forking and making a custom actions workflow to auto-patch each update so it feels like I am on the nightly+my patch with no effort. I'm happy at least it works for me but it's a shame they auto rejected the pr for everybody else.
well guess what i got theo to merge in all the grok fixes last night so no need to do that anymore!:3
Reacted by Harshit Pant and FenrisI tried to fix it but my PR got rejected by his GPT bot saying the code touched a vouched PR in progress. So there went that. I ended up forking and making a custom actions workflow to auto-patch each update so it feels like I am on the nightly+my patch with no effort. I'm happy at least it works for me but it's a shame they auto rejected the pr for everybody else.
well guess what i got theo to merge in all the grok fixes last night so no need to do that anymore!:3
great work @1xpixi can you also annoy him to look into this? Based on his tweet Opencode should be able to recognize skills in stable by now, but it still doesn't. Also, any idea why we do not show context window info like we do for codex

Note
🤖 GPT-5.6 Sol responding on behalf of Theo
Fixed by PR #8358, PR #9180, and PR #9154.
Grok now reads its native skill catalog with
grok inspect --json, uses the selected workspace directory, and supplies those skills to the composer on web and mobile. The health check also no longer starts a full ACP session. This closes the reported missing Grok skills and related provider health path. I did not reproduce the old BigInt crash separately.Reacted by Anthony Cook


Before submitting
Area
packages/contracts or packages/shared
Steps to reproduce
Install Grok CLI and ensure skills exist under ~/.grok/skills/ (or project .agents/skills/).
2. Confirm native Grok sees them:
grok inspect --json | jq '.skills | length'
also works: open native TUI and type
/or/skillsExpected behavior
Skils should be visible
Actual behavior
Skills are not when we use grok
Impact
Major degradation or frequent failure
Version or commit
No response
Environment
ready) - Grok CLI:0.2.103(grok agent stdio) - OS: macOS (arm64) - Provider cache (~/.t3/caches/grok.json):status: "ready", models present (grok-4.5,grok-build), but: -"skills": []-"slashCommands": []- Claude in the same install: slash commands populate normally (~90 commands)Logs or stack traces
SyntaxError: Cannot convert skills-reload to a BigInt at BigInt (<anonymous>) at RequestId (.../effect/.../RpcMessage.js) at .../effect/.../RpcClient.js at effect-acp/AcpClient.make at checkGrokProviderStatus / startSessionScreenshots, recordings, or supporting files
No response
Workaround
Using it in terminal for grok