Linux desktop client crashes on startup

I can also say that this problem appears to have been fixed in the last few days, after the upgrade from 1password 8.12.0 to 8.12.2.

I am running on Arch Linux with 1password installed from the AUR.

I was experiencing this crash report on startup reliably - probably 90% of the time. However, in my reboots over the last few days it is no longer occurring.

I believe this is likely the upgrade that fixed it:

https://aur.archlinux.org/cgit/aur.git/commit/?h=1password&id=4e812cfd70e28eb66e65c070ec76d9df9fd2df09

Thanks to the 1password devs for whatever they did to fix it... although it doesn't seem to be mentioned at all in the release notes here:

https://releases.1password.com/linux/stable/

I can say that in my case, Kubuntu 25.10, the problem appears to have disappeared with a recent release🤞Before, I was getting this consistently after every reboot, every time. Not to jinx it, but so happy this is finally resolved (at least in my case).

Just a very quick followup and THANK YOU.  The fix suggested to 

Clearing that directory (rm -rf ~/.config/1Password/crashes/*) before launching resolves the problem immediately.

works as advertised.  Thank you so much.

Hi, I didn't expect to find this thread. But, it looks like it is an known issue. I would just like to add on my experience - a message I made before I knew of this thread.

I have an issue where 1password reports an error upon startup, then after 40 seconds shows the login screen.

Consistent after reboots.

linux mint where are the log files stored: ~/.config/1Password/logs.

Executable: /usr/bin/1password links to /opt/1Password$

I have tried removing and reinstalling password-latest.deb ver 8.12.0

The following errors are selected from ~/.config/1Password/logs/1Password_rCURRENT.log file

ERROR 2026-02-10T19:47:15.556+00:00 ThreadId(16) [1P:data/op-db-queue/src/operations.rs:1222] transaction tx#39(list_objects_for_all_accounts) failed, will rollback: Invalid column type Text at index: 1, name: data

ERROR 2026-02-10T19:47:16.418+00:00 ThreadId(16) [1P:data/op-db-queue/src/operations.rs:1272] transaction tx#58(objects_mut) failed, will rollback: Invalid column type Text at index: 1, name: data

ERROR 2026-02-10T19:47:16.418+00:00 runtime-worker(ThreadId(10)) [1P:/mnt/ephemeral/builds/dev/core/core/op-syncer-component-item-usage-reports/src/lib.rs:30] Invalid column type Text at index: 1, name: data

INFO 2026-02-10T19:47:16.505+00:00 runtime-worker(ThreadId(4)) [1P:op-b5-client/src/b5_client/features/mod.rs:381] Using feature-rollout-service for pre-registration features.

ERROR 2026-02-10T19:47:16.523+00:00 runtime-worker(ThreadId(10)) [1P:data/op-syncer/src/system_vault.rs:29] Error creating system vault for account (JLOIFIQBJNHTRP7DF3T3VGEHNE): FetchDataError(FetchError(<unknown reason>, code: HttpStatus(400), Session ID: Some(Session ID: OJNYO3GJW5D7HIWNBWQ26ZXXGU)))

ERROR 2026-02-10T19:48:43.552+00:00 runtime-worker(ThreadId(9)) [1P:native-messaging/op-native-core-integration/src/connection_handler.rs:92] message from b5x was None: EndConnection

ERROR 2026-02-10T19:48:43.552+00:00 runtime-worker(ThreadId(9)) [1P:native-messaging/op-native-core-integration/src/connection_handler.rs:56] Dropping connection with b5x due to error handling incoming message: EndConnection

The time lag isnt a fatal issue, just an annoyance. Any insights would be appreciated.

Thanks

1Password file: 1password-latest.deb ver 8.12.0

System OS: Linux Mint 22.3 Zena

System Hardware: ASUS ROG Strix GL702VS-AH73 Gaming Laptop

I just wrote this reply and in doing so something occurred to me: It's insane that it has got to the point where users are explaining in detail what the bug is and how to fix it (and it's not just me – other users have pointed out what's wrong as well), and still nobody on the dev team is doing anything about it. We could not have made it any easier.

This bug in particular is what's making me think that I will not be renewing my 1Password subscription. I like 1Password on the whole, but this is very poor, and frankly it seems my money would be better spent elsewhere. There is no excuse for not fixing this bug now that it has been made so plain what is causing the problem. (Or maybe there is an excuse? If it's not as simple as we think, why not ask us for advice? We've already shown that we're capable of figuring this stuff out.)

1P_Dave​ When did you last speak to the dev team about this, and what did they actually say? Are they working on it, or is it just in a backlog somewhere, busy being ignored? Are they aware of the diagnoses that various users have made here?

Please can we bring this back on topic 🥺: on Linux, 1Password leaves stale files in ~/.config/1Password/crashes/ during a normal shutdown or reboot. On the next start, 1Password misinterprets these as a previous crash, logs a false crash, and delays startup. Clearing that directory (rm -rf ~/.config/1Password/crashes/*) before launching resolves the problem immediately. The discussion should focus on why crash artifacts persist across clean shutdowns and why they’re treated as real crashes on startup.

This is down to 1Password thinking that SIGTERM is a crash for some reason. You can get around it by deleting `.config/1Password/crashes/*` before starting the application, which you can put in a script and run on startup. The proper fix is, of course, not to interpret an external signal as a crash so the crash reporter needs fixing.

My guess is that SIGTERM is sent to everything still running when user session is stopped. It is a completely normal application signal and not a crash.

It wouldn't be so bad if the crash reporter didn't take ages to run. It does though. Even not sending a report isn't instant, which seems wild!

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)