Linux desktop client crashes on startup

Over 2 years since the Bug was reported and its still not fixed. 1P_Dave​ frankly, your statement that this issue is important to you cannot be true.

How would you react if you bought a brand new car and the dealer mentions on your way out: Oh and by the way, this car wont start on first try, just wait a couple of seconds and then try again. We are on it and will update you soon.

Please fix this asap, this affects our daily operation. Thanks

I've been experimenting with this and after a bit of reverse engineering I managed to hack together a fix. The fix is simple in principle but it's quite a technical process. I thought I'd share it for those who want to try it. I'll describe the process for x86 because that's all I've tried, but you could probably do something similar on ARM.

As Dave figured out here, it seems like 1Password is not actually crashing (but it might as well be). The error message refers to an improper exit when 1Password was last running. There's a bug which means that 1Password takes ages to start up properly after the error message is dismissed, and an error message followed by nothing happening looks like a crash. The reason this happens on boot is, I think, because 1Password doesn't properly exit when the system is shutting down (unless it is manually closed first). When 1Password is launched after the system has booted, it checks for evidence of an unclean exit when it was last running. It will find this evidence because it didn't exit correctly on the previous shutdown. When it finds the evidence, it shows the popup and triggers the startup delay bug.

The "fix" is to patch 1Password so that it never sees any crash reports from the unclean exit. The function to patch is op_crash_reporting::crash_report::CrashReport::check_for_crash_reports, and it is in the binary /path/to/1Password installation/resources/app.asar.unpacked/index.node. On my Manjaro system this is /opt/1Password/resources/app.asar.unpacked/index.node.

Before it actually looks for any crash reports, check_for_crash_reports checks if op_crash_reporting::killswitch::CRASH_REPORTING_KILL_SWITCH is enabled. If it is, then it just returns zero, as though there are no crash reports. This is compiled as a conditional jump: "if the kill switch is enabled, then jump to the bit that returns zero". We patch the jump instruction so that it always jumps to the bit that returns zero, regardless of whether the kill switch is set. The caller of the function is led to believe that there are no crash reports, so 1Password starts normally, without a popup or delay.

The code moves around between 1Password versions (I've tried 8.11.12 and 8.11.14), so to find the exact location of the instruction to patch we use objdump to find the function by name and disassemble it:

objdump -FC -Mintel --disassemble="op_crash_reporting::crash_report::CrashReport::check_for_crash_reports" /opt/1Password/resources/app.asar.unpacked/index.node

Here's my annotated version of the relevant part of the output of that command (on 8.11.14):

                        | 000000000468d280 <op_crash_reporting::crash_report::CrashReport::check_for_crash_reports> (File Offset: 0x468c280):
                        |  468d280:       55                      push   rbp
                        |  468d281:       41 57                   push   r15
                        |  468d283:       41 56                   push   r14
                        |  468d285:       41 55                   push   r13
                        |  468d287:       41 54                   push   r12
                        |  468d289:       53                      push   rbx
                        |  468d28a:       48 81 ec 08 01 00 00    sub    rsp,0x108
                        |  468d291:       48 89 f3                mov    rbx,rsi
                        |  468d294:       49 89 fe                mov    r14,rdi
                        |  468d297:       48 8b 05 c2 2c 07 03    mov    rax,QWORD PTR [rip+0x3072cc2]        # 76fff60 <op_crash_reporting::killswitch::CRASH_REPORTING_KILL_SWITCH> (File Offset: 0x76fef60)
                        |  468d29e:       48 83 f8 02             cmp    rax,0x2
                        |  468d2a2:       0f 85 3b 02 00 00       jne    468d4e3 <op_crash_reporting::crash_report::CrashReport::check_for_crash_reports+0x263> (File Offset: 0x468c4e3)
 (load kill switch) --> |  468d2a8:       0f b6 05 b9 2c 07 03    movzx  eax,BYTE PTR [rip+0x3072cb9]        # 76fff68 <op_crash_reporting::killswitch::CRASH_REPORTING_KILL_SWITCH+0x8> (File Offset: 0x76fef68)
(check kill switch) --> |  468d2af:       a8 01                   test   al,0x1
          THIS JUMP --> |  468d2b1:       0f 84 95 01 00 00       je     468d44c <op_crash_reporting::crash_report::CrashReport::check_for_crash_reports+0x1cc> (File Offset: 0x468c44c)
                        |  468d2b7:       48 8d 7c 24 20          lea    rdi,[rsp+0x20]
                        |  468d2bc:       4c 89 f6                mov    rsi,r14
                        |  468d2bf:       48 89 da                mov    rdx,rbx
                        |  468d2c2:       e8 19 05 00 00          call   468d7e0 <op_crash_reporting::crash_report::crash_files> (File Offset: 0x468c7e0)

(The disassembly for 8.11.12 looks much the same, except that the memory addresses are different. Until this function is modified significantly in an update, it should be possible to identify the instructions above in future versions of 1Password.)

The instruction to patch is the je marked "THIS JUMP". We can read its memory address from the column on the left (here, it's 0x468d2b1). We need the file offset so we can edit the instruction. The difference between the memory addresses and file offsets is the difference between the two hexadecimal numbers on the first line of the disassembly: in this case, it's 0x468d280 - 0x468c280 = 0x1000. So the offset of the target instruction in the file is 0x468d2b1 - 0x1000 = 0x468c2b1 for this version. (The file offset of the target instruction is not always the same. It's different (0x2d7d9e1) in 8.11.12, for example.)

Open index.node in a hex editor and go to the file offset just calculated (0x468c2b1 for me). You should see the bytes 0f 84 xx xx xx xx (0f 84 95 01 00 00 in this case). Change the first two bytes to 48 e9. This changes the je instruction to jmp, which is an unconditional jump.

To save the file you will likely need root access, so it might be easiest to save elsewhere and sudo mv it into the correct location. I recommend keeping the old file as a backup. For instance, my unpatched binary is at /opt/1Password/resources/app.asar.unpacked/index.node.unpatched. The patched binary goes where the original was, so 1Password will use it instead. If you mess up the patch and 1Password stops working, you can just go back to the original binary without needing to reinstall anything.

You'll have to reapply the patch every time 1Password is updated. I did when I went from 8.11.12 to 8.11.14.

For what it's worth, I used to have this issue for probably a year or two. But, at some point in the last month or so, the crashing on startup went away.

App: 1Password for Linux 8.11.14 (81114024)

Browser: Firefox 144 (Snap)

OS: Ubuntu 25.10 (Wayland)

I find it astonishing that this has not yet been fixed. Clearly it is not an issue of reproducibility because apparently it was reproduced internally four months ago. Is it difficult to fix? Is it low priority because Linux users are expected to be able to deal with unpolished software? Or because Linux users are (presumably) a small proportion of 1Password's (paying!) customer base, and therefore not worth the time?

Please excuse the tone; I bear no ill will towards anyone at 1Password, especially not Dave and the rest of the community team who have the unfortunate job of updating people on this when there are no updates to give. But it's extraordinary that a bug like this has survived several production releases of a commercial piece of software after having been reported a year ago.

For me to make it a bit workable, I disconnected the (Firefox) 1Password plugin from the desktop app in the plugin settings. Now it doesn't crash when using it in the browser (my (almost) only usecase ). But yeah, not a real solution ofcourse. 

Created an account to reply to this - Marking this as resolved is HIGHLY misleading as this has been a year in the works and is NOT resolved. I have tried all of the different versions of Linux, tried Snap, .deb, and any other package types I could find, tried settings changes, and there has been and is STILL NO FIX. 

I have been very happy with 1Password, but over the last year a LOT of my devices and my computers have moved to linux and the amount of time this issue wastes is ridiculous. It can take anywhere from 1-5 minutes after launching to actually have the 1Password program launch and function after a reboot. I work in IT, I understand that's not all that much time for a one time thing. But EVERY TIME I reboot? That can easily take a "quick fix" to a well I guess I will do this later" if I am in a hurry. 

WHEN is a fix coming?? Is there any news other than "oh we're working on it!" 

You wrote in February, we should watch the release log for a fix. But nothing happend since then.

1Password is still crashing every morning on Ubuntu 25 with version 8.10.78

Any plans of solving this problem?

Here’s what fixed the “crash/slow first launch, then fine after” issue for me on Ubuntu Asahi (ARM64). Maybe it helps others hitting the same thing.

First launch after a reboot hangs ~30s or “crashes,” then later launches are instant.

Logs show lines like:

GLib-GObject … has no handler with id …
sending crash reports (then a long pause)

After it finally starts, DB integrity checks succeed and the app is snappy until next reboot.

The crash reporter was blocking startup on the first run after boot. Disabling it removed the delay.

Quick test (no install changes)

Run 1Password once like this:

/opt/1Password/1password --disable-crash-reports

1Password doesn’t provide a Flatpak build for ARM64, and I haven’t seen this issue on my other machine running AMD64.

Usually wouldn't pile on a thread with plenty of information just to +1, but considering this has been an issue for so long, thinking it might help raise the pressure a bit 🙂

On Kubuntu 25.04 this happens after every restart - first a crash, then it opens. Sometimes though, seemingly especially after 1Password being updated, it refuses to start entirely until I run `sudo pkill 1password` and open it again.

It's really annoying and after experiencing this for over a year now personally I'm seriously close to looking for alternatives... which is a real shame considering how happy I am with 1PW otherwise...

Come on guys! Why is this not fixed!! I have this every day, every time I start my Ubuntu 25.04 and use Firefox and 1Password or 1Password directly. 

Every time I report this, and more then a year(?!) this is not fixed. Am I paying for something or not?