CLI agent binary name collision with Grok CLI — login goes to wrong OAuth provider

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

When both Grok CLI and Cursor CLI are installed on macOS, running agent login opens the Grok OAuth page (Grok) instead of Cursor’s OAuth page. After authenticating, agent models shows only “grok-4.5” as the available model instead of Cursor’s full model catalog (Claude, GPT, etc.). The Cursor CLI appears to detect and use the Grok CLI’s cached authentication (~/.grok/auth.json) instead of its own auth flow.

Steps to Reproduce

1. Install Grok CLI: curl -s https://grok.com/install | bash
2. Install Cursor CLI: curl https://cursor.com/install -fsS | bash
3. Run agent login
4. Browser opens grok.com OAuth instead of cursor.com
5. Authenticate with grok.com credentials
6. Run agent models

Expected Behavior

agent login should open Cursor’s OAuth page (cursor.com) and agent models should show Cursor’s model catalog (Claude Sonnet, GPT-4, etc.), not Grok’s models

Operating System

MacOS

Version Information

  • Cursor CLI: 2026.07.17-3e2a980 (removed during debugging)
  • Grok CLI: 0.2.106 (bde89716f679)
  • macOS: 26.5.1 (Apple Silicon)

For AI issues: which model did you use?

N/A — CLI auth issue, not model-related.

Additional Information

Both CLIs install a binary named agent to ~/.local/bin/. The last-installed one overwrites the symlink. Suggest unique binary names (e.g., cursor-agent for Cursor, grok-agent for Grok) or a namespace prefix to avoid collisions.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report. This isn’t a Cursor auth flow bug, it’s a binary name collision.

Both Grok CLI and Cursor CLI install an executable named agent into ~/.local/bin. Whichever one was installed or updated last overwrites the symlink. Right now agent points to the Grok binary, so agent login opens grok.com and agent models only shows grok-4.5. Cursor CLI isn’t being called at all. It doesn’t read ~/.grok/auth.json, the agent command is simply resolving to Grok.

The easiest fix is to run Cursor CLI via cursor-agent. Cursor installs this separate symlink next to agent, and you already have it in ~/.local/bin. It points directly to the Cursor binary and doesn’t conflict with Grok, so cursor-agent login, cursor-agent models, etc will work with Cursor no matter who currently owns agent.

If you want the agent name to point back to Cursor, reinstall the CLI via curl https://cursor.com/install -fsS | bash, but note that the next Grok auto update might grab it again. So cursor-agent is the more stable option.