Repository navigation
[Bug]: Grok provider ACP startup times out on Linux when Grok emits unsolicited skills-reload JSON-RPC responses #3666
Description
Activity
I asked Grok to analyze this issue and it basically says that the WSL T3 server needs to run in a WSL Linux directory not a Windows path.
So Grok is fine on Linux paths, but when T3 probes with /mnt/c/..., 9/10 times it will sit near or over the 15s limit. That matches the error.
T3 launches the probe with cwd: process.cwd() of its server, not your project folder — so a Windows-mounted home is enough to break Grok model discovery even if Grok works in the terminal.
Fixes (in order)
- Prefer working from native Linux paths
Open projects under Linux FS, e.g.:
• /opt/dev/peakbot/...
• /home/danielcor/...Avoid /mnt/c/... as the main workspace for agent work.
- Start T3’s server from a Linux cwd
Your running server:
node .../t3code/.../bin.mjs
cwd → /mnt/c/Users/danieRestart T3 so the WSL server starts in something like:
cd /home/danielcor # or /opt/dev/peakbot
then launch T3 Code again
If you launch T3 from Windows, configure it to open WSL with a Linux home/cwd rather than C:\Users\danie.
- Point Grok at an absolute binary (good hygiene)
In T3 Settings → Grok:
• Binary path: /home/danielcor/.local/bin/grok
(Right now only Cursor is stored under providerInstances in ~/.t3/userdata/settings.json; Grok is using defaults / UI state.)
- Optional: lighten Grok startup
Your ~/.grok/config.toml has remote MCP (linear, open-brain). Unlikely to be the main issue vs /mnt/c, but if probes still hover near 15s, temporarily set those to enabled = false and re-check.
Quick verify
From WSL:
Should be fast (~0.5s total)
printf '%s\n'
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":1,"clientCapabilities":{},"clientInfo":{"name":"t","version":"0"}}}'
'{"jsonrpc":"2.0","id":2,"method":"authenticate","params":{"methodId":"cached_token"}}'
'{"jsonrpc":"2.0","method":"notifications/initialized","params":{}}'
'{"jsonrpc":"2.0","id":3,"method":"session/new","params":{"cwd":"/tmp","mcpServers":[]}}'
| timeout 10 grok agent stdio | headThen in T3: refresh Grok provider status after restarting with a Linux cwd.
Bottom line
• Grok CLI is fine
• T3’s 15s ACP probe is borderline when the server cwd is /mnt/c/Users/danie
• Fix by making T3’s WSL process (and ideally workspaces) use native Linux paths, not Windows mountsThis is also a reasonable bug report for T3 Code: provider model discovery should not use process.cwd() on a Windows /mnt/c path; it should use /tmp or $HOME on the Linux side.
- Prefer working from native Linux paths
Thanks for the detailed report. We believe this is fixed by PR #4643 and PR #5331.
The reported skills-reload frame killed the old Effect RPC client because RequestId converted the string to BigInt. The dependency upgrade replaced request IDs with string-or-number IDs. The current client accepts the string and ignores an exit with no matching request, so this exact unsolicited-response failure no longer kills ACP. Slow MCP or WSL working directories remain a different timeout cause.
I'm closing this as fixed as part of an automated pass on all open issues. If this still happens in a current build that includes PR #4643 and PR #5331, please reply with the T3 Code version and fresh logs or reproduction details, and we can reopen it.
Before submitting
Area
apps/desktop
Steps to reproduce
Expected behavior
T3 Code should tolerate unrelated or unsolicited JSON-RPC responses/notifications while waiting for the response to its own request IDs, and complete Grok ACP startup.
Actual behavior
On Linux, T3 Code fails Grok provider startup with:
Unavailable - Grok CLI is installed but ACP startup timed out after 15000ms.
The Grok CLI itself works. Running grok agent stdio directly can initialize, authenticate, and create a session successfully outside T3 Code.
During ACP startup, Grok emits unsolicited JSON-RPC response messages like:
{"jsonrpc":"2.0","id":"skills-reload","result":{"result":{"reloaded":0}}}
These messages appear before or around the normal authenticate/session startup flow. T3 Code appears to hang or time out when these messages are present.
Impact
Blocks work completely
Version or commit
T3 Code: AppImage 0.0.28 | Grok CLI: 0.2.82 stable
Environment
Linux Mint 22.3
Logs or stack traces
Screenshots, recordings, or supporting files
No response
Workaround
I created a local wrapper that proxies grok agent stdio and filters only lines containing:
"id":"skills-reload"
With that wrapper configured as the Grok binary, Grok becomes usable inside T3 Code.
Why I think this is the issue:
The wrapper does not change auth, PATH, cwd, or Grok startup. It only removes the skills-reload JSON-RPC response lines from Grok stdout. After that, T3 Code can use Grok normally.