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

@RyanHecht

@RyanHecht It hangs indefinitely, here's me waiting for about a minute:

EDIT: Ah, looks like I can't upload video, anyway it does.

Thank you! Going to work on an improved experience for this edge case in the absence of knowing the root cause

@RyanHecht

@RyanHecht Do you want me to dump the process or anything? That's probably what I'd do in this situation, but I'm not a node guy so I'm unsure if it helps you.

@RyanHecht

@RyanHecht I collected a dump of node process when it had been stuck like this for about a minute:

https://www.dropbox.com/scl/fi/xlfzcapsj536fdxa70oqx/node_dump.zip?rlkey=cgi441g01dc8zuohhdbb7pp43&dl=0

I understand you could look at the stack traces in llnode (https://github.com/nodejs/llnode)

This is fixed in 0.0.335!

@RyanHecht

Hi @RyanHecht ,

I just gave 0.0.335 a try and unfortunately the behavior is pretty much the same as before. (Although it may be flickering more on reauth?)

@benstaniford

Oh no! And even after manually visiting the the page and entering the code, it still hangs there? @benstaniford

@RyanHecht

@RyanHecht I'm afraid so yeh :-(

Do you want me to collect any further dumps or anything? I'm happy to get stack traces or whatever of what the program is doing during that hang.

@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

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

benstaniford 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

benstaniford commented on Oct 7, 2025

RyanHecht commented on Oct 7, 2025

benstaniford commented on Oct 7, 2025

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