Repository navigation
Authorization always hangs and then you can't quit copilot (might be related to not being able to launch browser in SSH session) #89
Description
Activity
- changed the title
[-]Authorization always hangs and then you can't quit copilot[/-][+]Authorization always hangs and then you can't quit copilot (might be related to not being able to launch browser in SSH session)[/+]on Oct 1, 2025 I have the same error in the latest stabel release.
im also sshd into a raspi...
I can shutdown if i havent done /login yet but after being in the loop it doesnt
Reacted by Ben Staniford and David EspinozaSame here, im using ubuntu server 24.
Did you guys try the authentication adding the env as documentation says?
Even tho that authentication process isn't working, I solved it that way.
@despinozap Thanks, that's a good workaround! For some reason that particular permission is only available in the "public repositories" scope, so I've had to create a second PAT token specifically for copilot. However, it works.
The following alias helps use it without trampling my regular github PAT.
alias copilot='GH_TOKEN=$COPILOT_PAT /usr/local/bin/copilot'@benstaniford Cool! I also created a new token for that.
I'd like to be using that auth process but that's still broken in the callback flow or something like that I guess.
Well.. at least we can start playing around with the cli meanwhile it's fixed 🙌Reacted by Ben Staniford@benstaniford the workaround doesnt work on my machine... maybe im just to dumb:
(venv) bennet@raspberrypi:~ $ alias copilot='GH_TOKEN=ghp_(my github pat) /usr/local/bin/copilot'
(venv) bennet@raspberrypi:~ $ copilot
Welcome to GitHub Copilot CLI
Version 0.0.331 · Commit eb0ae04Copilot can write, test and debug code right from your terminal. Describe a
task to get started or enter ? for help. Copilot uses AI, check for mistakes.Please use /login to sign in to use Copilot
~
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────Enter @ to mention files or / for commands
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Ctrl+c Exit · Ctrl+r Expand RecentThank you for youre help!
@joan-code6 That looks ok.. Does your PAT token have the correct "Copilot Requests" permission?
We should have a page that looks like this when we can't get your clipboard/can't launch your browser:
today I'll look into why this might not be firing correctly on SSH sessions --
I wonder if it's relevant that you're both on Raspberry Pi, toonevermind, saw the Ubuntu Server report as wellQuestion: are you folks all SSH'd using VSCode remote? And can you still reproduce this bug if you SSH outside of VSCode?
@RyanHecht Thanks for looking into it!
are you folks all SSH'd using VSCode remote? And can you still reproduce this bug if you SSH outside of VSCode?
No, I'm using plain old Windows Terminal and the SSH version that comes with Git for Windows.
@RyanHecht I've just tried PuTTY as well, and I can reproduce the same issue with that.
Thanks for trying that for me @benstaniford! One more thing to try: If you manually go to https://github.com/login/device and enter your code, does it continue to hang, or does it eventually complete after ~30 seconds?
(Sorry to keep sending you on fetch quests, but I haven't been able to reproduce this via SSH-ing into any of my machines thus far!)
9 remaining items
Hey again @benstaniford -- we made another change in 0.0.337 that should enable polling as soon as we generate the device code -- can you see if it properly lets you sign in now?
I'm sorry @RyanHecht but there's been no change in behavior except that it now keeps "Enter one-time code" on the scren.
I'm not sure if this helps, but I captured an strace of the attempt and I notice that when it hangs after I attempt to ctrl-c, copilot handles the SIGINT but gets a bad file descriptor error. Could that hint at why it's hanging?
@RyanHecht I also tried connecting to the hung process with gdb (after I hit ctrl-c). Here's a text file with what all the node threads were doing:
The main thread seems to be waiting for workers to finish
#6 0x00007fffb84af6a0 in uv_thread_join () at /lib/aarch64-linux-gnu/libuv.so.1 #7 0x00007fffb849be2c in ??? () at /lib/aarch64-linux-gnu/libuv.so.1 #8 0x00007fffb916411c in node::DefaultProcessExitHandlerInternal(node::Environment*, node::ExitCode) () at /lib/aarch64-linux-gnu/libnode.so.115 #9 0x00007fffb91bfe54 in node::Environment::Exit(node::ExitCode) () at /lib/aarch64-linux-gnu/libnode.so.115 #10 0x00007fffb96a56bc in v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) () at /lib/aarch64-linux-gnu/libnode.so.115 #11 0x00007fffb96a5bb8 in ??? () at /lib/aarch64-linux-gnu/libnode.so.115 #12 0x00007fffb96a62c8 in v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) () at /lib/aarch64-linux-gnu/libnode.so.115 #13 0x00007fffb9530964 in ??? () at /lib/aarch64-linux-gnu/libnode.so.115 #14 0x00002396bb9e4971 in ??? ()...and the workers seem to be attempting to cancel a system call? (Not a linux expert). There's an interesting one doing some password stuff:
Thread 5 (Thread 0x7fff9dfaf060 (LWP 82374) "libuv-worker"): #0 __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/aarch64/syscall_cancel.S:50 #1 0x00007fffb85b2658 in __internal_syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=8, a6=a6@entry=0, nr=nr@entry=73) at ./nptl/cancellation.c:49 result = <optimized out> pd = <optimized out> ch = <optimized out> #2 0x00007fffb85b269c in __syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=8, a6=a6@entry=0, nr=nr@entry=73) at ./nptl/cancellation.c:75 r = <optimized out> #3 0x00007fffb8613b0c in __GI_ppoll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/ppoll.c:42 tval = {tv_sec = 476052, tv_nsec = 140735843853136} #4 0x00007fff9c461874 in ??? () at /lib/aarch64-linux-gnu/libglib-2.0.so.0 #5 0x00007fff9c462424 in g_main_loop_run () at /lib/aarch64-linux-gnu/libglib-2.0.so.0 #6 0x00007fff9c5c2300 in secret_password_storev_sync () at /lib/aarch64-linux-gnu/libsecret-1.so.0 #7 0x00007fff9c5c2524 in secret_password_store_sync () at /lib/aarch64-linux-gnu/libsecret-1.so.0 #8 0x00007fff9c61e9d0 in keytar::SetPassword(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) () at /usr/local/lib/node_modules/@github/copilot/node_modules/keytar-forked-forked/build/Release/keytar.node #9 0x00007fff9c6152d8 in SetPasswordWorker::Execute() () at /usr/local/lib/node_modules/@github/copilot/node_modules/keytar-forked-forked/build/Release/keytar.node #10 0x00007fff9c61af84 in Napi::AsyncWorker::OnAsyncWorkExecute(napi_env__*, void*) () at /usr/local/lib/node_modules/@github/copilot/node_modules/keytar-forked-forked/build/Release/keytar.node #11 0x00007fffb920a854 in node::ThreadPoolWork::ScheduleWork()::{lambda(uv_work_s*)#1}::_FUN(uv_work_s*) () at /lib/aarch64-linux-gnu/libnode.so.115 #12 0x00007fffb849b9b0 in ??? () at /lib/aarch64-linux-gnu/libuv.so.1 #13 0x00007fffb85b5f78 in start_thread (arg=0x7fff9dfaf060) at ./nptl/pthread_create.c:448 ret = <optimized out> pd = 0x7fff9dfaf060 out = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {32, 8388608, 140735843854520, 140736338752576, 140736286383072, 0, 140736901339175, 6, 140735835406336, 140735843856480, 140735843854608, 6209870562365425774, 0, 6209870562975806118, 0, 0, 0, 0, 0, 0, 0, 0}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = 0 #14 0x00007fffb861de8c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone3.S:76Hi @benstaniford, since it looks like the issue here is writing to the system keychain we added a workaround in 0.0.338. If you update and add:
"store_token_plaintext": true
to your
~/.copilot/config.jsonfile that will default to storing your OAuth token in the config.json file (in plaintext⚠️ ) and skip attempting to use the system keychain.Also thank you for the thorough debugging here! 🙌
I hit this on a stock fedora machine -- is there guidance on what to do for system keychain on Linux? I'm happy to install something but it's unclear what's supported.
It doesnt work on my machine what did i do wrong...
(venv) bennet@raspberrypi:~ $ alias copilot='GH_TOKEN=ghp_mypat /usr/local/bin/copilot'
(venv) bennet@raspberrypi:~ $ nano ~/.copilot/config.json{
"store_token_plaintext": true,
"banner": "never",
"theme": "dark",
"trusted_folders": [
"/home/bennet/zen_ai",
"/home/bennet"
]
}(venv) bennet@raspberrypi:~ $ alias copilot='GH_TOKEN=ghp_mypat /usr/local/bin/copilot'
(venv) bennet@raspberrypi:~ $ copilot
Welcome to GitHub Copilot CLI
Version 0.0.331 · Commit eb0ae04Copilot can write, test and debug code right from your terminal. Describe a
task to get started or enter ? for help. Copilot uses AI, check for mistakes.Please use /login to sign in to use Copilot
~
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────Enter @ to mention files or / for commands
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Ctrl+c Exit · Ctrl+r Expand RecentThis appears to have been addressed across several releases. v0.0.335 specifically fixed the SSH browser-launch hang reported here, and later releases (through v1.0.10) added safeguards around system keychain access -- including a timeout on keychain operations -- to prevent the indefinite hangs seen when no keyring daemon is running. There is also a
store_token_plaintext: trueconfig option for environments where the system keychain is unavailable. If you are still seeing this on a current version, please feel free to reopen with your CLI version and environment details.
Describe the bug
When I attempt to authorize, I'm doing so on a linux arm64 machine that I'm ssh'd into. I get the device code and go to the URL specified on my main browser and then I I hit enter to say I've copied the device code manually. I then authorize on the website successfully, and then copilot hangs with this screen:
I've tried varying the order of authenticating and hitting enter and I've tried authenticating a total of 6 times now over several days. I have no problems with my internet connection and the machine I'm logged into has no problem talking to copilot more generally (I'm using the VS code copilot on there).
Additionally, when I try to ctrl-c out of the "Waiting for authorization", that also hangs giving me this:
Affected version
0.0.328
Steps to reproduce the behavior
When I attempt to authorize, I'm doing so on a linux arm64 machine that I'm ssh'd into. I get the device code and go to the URL specified on my main browser and then I I hit enter to say I've copied the device code manually. I then authorize on the website successfully, and then copilot hangs with this screen:
I've tried varying the order of authenticating and hitting enter and I've tried authenticating a total of 6 times now over several days. I have no problems with my internet connection and the machine I'm logged into has no problem talking to copilot more generally (I'm using the VS code copilot on there).
Additionally, when I try to ctrl-c out of the "Waiting for authorization", that also hangs giving me this:
Expected behavior
I should be able to authenticate
Additional context
OS: Debian Trixie Linux on ARM64 Raspberry Pi 5