[Bug]: Grok provider ACP startup times out on Linux when Grok emits unsolicited skills-reload JSON-RPC responses

[thanostourik]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Install and log in to Grok CLI.
2. Configure T3 Code Grok provider to use grok.
3. Start T3 Code provider discovery.
4. T3 reports: Unavailable - Grok CLI is installed but ACP startup timed out after 15000ms.

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.

[danielcor]

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)

1. 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.

2. Start T3’s server from a Linux cwd
   Your running server:

node .../t3code/.../bin.mjs
cwd → /mnt/c/Users/danie

Restart 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.

3. 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.)

4. 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 | head

Then 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 mounts

This 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.

[t3dotgg]

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.