CopilotC-Nvim
Proposal: Optimize Token Caching to Prevent Copilot Rate Limiting Issues
Currently, the token refresh mechanism only triggers on timeout. However, repeatedly opening/closing Neovim and sending a single request each time appears to result in Copilot API access restrictions (I've experienced 4 account suspensions, each occurring after this pattern).
I suspect this behavior might be triggering GitHub's abuse detection mechanisms due to frequent token reinitialization. To mitigate this, could we improve the caching logic to persist tokens more effectively across sessions?
Additionally, while less urgent, handling potential API concurrency (especially for chat requests) might further reduce edge-case risks. But this seems less critical compared to the token persistence issue.
The original oauth token is already cached, we are grabbing it from cache and then doing same thing as https://github.com/github/copilot.vim pretty much. We can cache the response from this request i guess but I never experienced this issue myself and havent seen anyone else with this issue using this plugin either so are you sure this plugin is the only thing you were using for accessing copilot when you got the abuse detection mail?
The original oauth token is already cached, we are grabbing it from cache and then doing same thing as https://github.com/github/copilot.vim pretty much. We can cache the response from this request i guess but I never experienced this issue myself and havent seen anyone else with this issue using this plugin either so are you sure this plugin is the only thing you were using for accessing copilot when you got the abuse detection mail?
Appreciate the response! 😊 Just to clarify: I'm only using CopilotChat.nvim for Copilot interactions.
My setup uses copilot.lua which caches the OAuth token in ~/.config/github-copilot/apps.json. Then, CopilotChat.nvim uses that OAuth token to request the v2/token endpoint. The actual chat requests use this temporary v2/token.
My theory: If we restart Neovim multiple times within a short period, each instance might be:
- Fetching the same cached OAuth token from copilot.lua
- But triggering fresh v2/token requests each time
Could this repeated v2/token regeneration (even with the same OAuth token) look like suspicious burst traffic to GitHub's API?
Totally get that this might be edge-case behavior! Just sharing my debugging journey as someone who compulsively restarts nvim 20 times a day 🫠
Yea I mean if its an issue we can always at least try to cache it. But one more thing I would verify is if it isnt copilot.lua issue, I am using copilot.vim and I would trust that one more than copilot.lua, can you reproduce this issue when using copilot.vim instead of lua?
That's a valid question, but I'm hesitant to test with copilot.vim because:
- I'd need to risk another account ban (even if reversible, the appeal process is cumbersome)
- My previous bans consistently correlated with frequent nvim restarts during system_prompt debugging sessions (during that period I barely used copilot.lua's autocomplete)
- Current setup (third-party chat API + copilot.lua) has been stable for 10+ days
I believe the core issue is unrelated to copilot.vim/lua implementations
Not requesting immediate action - just documenting this pattern for others' reference. Appreciate your openness to consider cache adjustments!
Now that vscode copilot chat is open source closing this is probably fine as it really should not be an issue and we are using the token generation as we are supposed to