Authorization always hangs and then you can't quit copilot (might be related to not being able to launch browser in SSH session)

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

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

Same 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

@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

@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 🙌

@benstaniford

@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 eb0ae04

Copilot 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 Recent

Thank you for youre help!

@joan-code6

@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, too~~ nevermind, saw the Ubuntu Server report as well

Question: are you folks all SSH'd using VSCode remote? And can you still reproduce this bug if you SSH outside of VSCode?

@RyanHecht

@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

@RyanHecht I've just tried PuTTY as well, and I can reproduce the same issue with that.

@benstaniford

Thanks for trying that for me @benstaniford! One more thing to try: If you manually go to http://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!)

@benstaniford

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?

@RyanHecht

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

@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:

gdb.txt

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:76

@benstaniford

Hi @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.json file 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! 🙌

@devm33

@devm33 Yep, that did it :-)

So do you think that's ARM64 related?

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 eb0ae04

Copilot 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 Recent

This 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: true config 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.

Navigation Menu

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

Describe the bug

Affected version

Steps to reproduce the behavior

Expected behavior

Additional context

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Describe the bug

Affected version

Steps to reproduce the behavior

Expected behavior

Additional context

Activity

joan-code6 commented on Oct 1, 2025

visual-alchemy commented on Oct 2, 2025

despinozap commented on Oct 2, 2025

benstaniford commented on Oct 3, 2025

despinozap commented on Oct 3, 2025

joan-code6 commented on Oct 5, 2025

benstaniford commented on Oct 6, 2025

RyanHecht commented on Oct 6, 2025

RyanHecht commented on Oct 6, 2025

benstaniford commented on Oct 6, 2025

benstaniford commented on Oct 6, 2025

RyanHecht commented on Oct 6, 2025

9 remaining items

RyanHecht commented on Oct 8, 2025

benstaniford commented on Oct 9, 2025

benstaniford commented on Oct 9, 2025

devm33 commented on Oct 10, 2025

benstaniford commented on Oct 11, 2025

agocke commented on Nov 9, 2025

joan-code6 commented on Nov 17, 2025

examon commented on Apr 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions