Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
1Password Chrome extension is incorrectly manipulating <code> blocks
The latest 1Password Chrome extension is incorrectly manipulating the DOM within <code> blocks on static pages. It looks it's using prism.js to try to add syntax highlighting to <code> blocks on the entire page. If you're using a static site generator to highlight code with a different library, it causes the display to break. Example: mkdocs, a popular documentation tool If you view the documentation for customizing Mkdocs material (https://squidfunk.github.io/mkdocs-material/customization/) with the extension enabled, you'll see that the YAML example at the top is not highlighted (it should be). Under the hood, if you inspect its DOM, you can see that it's been rewritten with prismjs classes. If you disable the extension, it is highlighted: This is likely to impact a number of documentation sites in the tech community.
1password input focus lag with lots of inputs
I'm running into an issue where 1password seems to significantly slow down interaction with the webpage I'm working on. There's a ton of input fields of which most are hidden, I cannot lower the amount of inputs, in fact I have to increase the amount of inputs due to how the system works. Every time I click on an input, the focus is delayed by ~200ms or so. The next time I select the same input field it's instant. 1password seems to do something that slows down the focus event. I made a performance recording in firefox. I selected 3 inputs and after the 3rd on selected the same 3 in the same order with no slowdown. I've tried adding data-1p-ignore and autocomplete="off" but it didn't solve anything.
Why the requirement for group id >= 1000?
In various places people have had to discover, and workaround the fact that the 1Password Browser-Helper and CLI not only require being in a specific group (fine), and have setgid set (also fine), but the gid of that group must by greater or equal to 1000 for the integration to work: Arch: Can not connect to desktop app | 1Password Community Gentoo: [SOLVED] Browser support error on Gentoo Linux | 1Password Community NixOS: https://github.com/NixOS/nixpkgs/commit/2a58907251af76c67c6d14c1e84e73f7eaeb95e8 I've been working on a distro package for a Linux distribution I'm building and also had to discover this. As per the previous implementation in the AUR, my package uses systemd-sysusers to automatically manage users and groups required by packages. By default these automatically assigned gids are less than 1000, which causes the browser integration to fail. I can work around by hard-coding a gid, but it would be better if it just worked with the automatically assigned one. I'm wondering what's the reason for the >= 1000 requirement, and can the need for it be removed to make packaging simpler, cleaner, and consistent with other packages that need specific users and groups.
1PW extension bug: autofill theme detection fails when using oklch color scheme
Hey, I am trying to fix the autofill background on a web app that has dark mode. Right now the 1Password extension applies light autofill background which creates unreadable contrast (1st screenshot). It's because input gets `data-com-onepassword-filled="light"` attribute with light variant. Is it possible to tell the 1PW that the page is using dark mode or what's the solution to let the 1PW set `data-com-onepassword-filled` to `'dark'`? I have set the color-scheme CSS property to `dark`. Edit: I managed to debug this issue and found out there's a bug in the theme detection by 1PW extension itself that's done via `data-com-onepassword-filled="light|dark"`. The reproduction is simple: When using `oklch` color on input text, the autofill detection breaks and resolves the theme always as light. <!DOCTYPE html> <html lang="en" style="color-scheme: dark"> <body> <h1>Working - uses hex</h1> <div style="color: #edeef0"> <input type="email" autocomplete="email" /> </div> <h1>Not working - uses oklch</h1> <div style="color: oklch(94.9% 0.003 264.5)"> <input type="email" autocomplete="email" /> </div> </body> </html> Which will result inNew getting-started guides, AI search, and LLM-ready docs for 1Password dev tools at 1password.dev
Hi everyone! We've been investing in making 1Password's developer documentation genuinely useful from the first click, and we wanted to share what's now live over at 1password.dev. 📖 New getting-started guides We've published workflow-based getting-started guides across every major tool area: SSH & Git, 1Password CLI, SDKs (Go, JavaScript, Python), Environments, integrations, and more. Instead of jumping between reference pages, you can follow a clear path from setup to working integration, organized around how you actually build. 🔍 AI-powered search across the docs You can hit Ctrl+K on any page and ask a question in plain language. The built-in AI assistant searches the full documentation set and gives you a direct answer with links to the relevant pages. It’s a much faster way to find what you need, especially if you’re not sure which tool or section to look in. Try it: open 1password.dev, hit ⌘+K, and type “How do I set up git commit signing with multiple GitHub accounts?” 🤖 Docs built for AI dev workflows If you use AI coding assistants like Cursor, Copilot, Windsurf, or Claude, our docs are now natively consumable. Every page is available as Markdown (append .md to any URL), and we serve llms.txt and llms-full.txt at the site root so your tools can reference 1Password docs directly. Details here: Build with LLMs 🏗️ Refreshed docs structure The documentation is now organized around the way developers work, with clearer navigation across SSH & Git, CLI, SDKs, Environments, secrets management, and integrations. If you've found our docs hard to navigate in the past, it's worth another look. 📌 One practical note: our developer docs now live at 1password.dev. All your existing developer.1password.com links and bookmarks redirect automatically, so nothing breaks. We'd love your feedback If you run into any issues or have suggestions, let us know in this thread. You can also reach us in the 1Password Developers Slack. Happy building! 🔐
Feature request: Path-aware login suggestions for multiple credentials on the same domain
I'd like to file a feature request and share a use case where the current "domain-only" matching makes day-to-day autofill noticeably worse, and to ask whether path-aware matching could be reconsidered as an opt-in option Up front: I can see from a quick search that this is clearly a much-requested feature, with threads going back what feels like several presidential administrations. Normally I'd just add a thumbs-up to the canonical request rather than start a new thread - but without a feature-request tracker (more on that at the end), I genuinely couldn't tell which of the many overlapping discussions is the "live" one the team is actually watching, vs. the ones now being slowly reclaimed by the forum equivalent of moss. So I'm posting fresh rather than guessing wrong and shouting into a tomb. Apologies for the duplication; please feel free to merge this into whichever discussion is currently canonical. ## The situation I have multiple distinct logins on the same domain, distinguished only by path. For example: - https://[example.com]/[teamA]/login -> Login A - https://[example.com]/[teamB]/login -> Login B - https://[example.com]/[admin]/login -> Login C Because 1Password matches on eTLD+1 and ignores the path for suggestions, all three credentials surface every time I land on any of these pages. There is no way to tell 1Password "when the URL path starts with /teamA, prefer Login A," which means every login attempt is a small multiple-choice quiz I am demonstrably bad at. ## Why this matters The "pick from a list" flow is fine for an occasional ambiguity, but in this scenario it happens on every single login. I autofill the wrong credential maybe 1 in 3 times, which - and I cannot stress this enough - triggers the account lockout flow on at least one of these systems. My password manager and I are, in effect, collaborating to lock me out of my own accounts. Favoriting helps for exactly one of them; the others remain a coin flip with worse odds. I understand from past forum threads that 1Password removed path matching some years ago because it complicated things for typical users, and that the team is (rightly) conservative about adding options. I'm not asking for the old behavior back as a default - I'm asking whether a per-item, opt-in path constraint could fit the existing model: - Today's "Fill anywhere on this website" -> unchanged default - Today's "Only fill on this exact host" -> already path-blind - New: "Only fill when URL path starts with ..." (per Website entry) That mirrors the existing exact-host option, just one level deeper. No regex, no globs, no Turing-complete URL DSL - just a path-prefix string on the Website field when the user explicitly opts in. Items without the new option behave exactly as they do today, so there's no impact on users who don't need this. ## Alternatives I've tried - Favoriting: only helps one of N items. - Exact-host: doesn't help because the host is identical. - Splitting into separate Website entries: doesn't help because the path is dropped from matching. - Open-and-fill from the 1Password app: works, but defeats the purpose of an in-browser password manager for daily logins - at that point I'm essentially using 1Password as a fancy bookmarks menu. ## A small meta note This connects to the situation I described at the top. I understand the team's reasoning for not running a formal voting system - that vote counts don't capture the "why" behind a request, and that discussion surfaces better signal. Both of those things are true. But the current setup also means there's no way for users with the same underlying problem to converge on a single canonical request, no visible signal of how widespread an issue is, and no acknowledgement loop telling requesters whether something is even on the radar. The current incentive structure rewards starting yet another duplicate thread (hi!) over piling onto an older one nobody can confirm is still being read. A lightweight feature-request tracker - even one without public vote counts, if that's the concern - would make it easier for users like me to contribute signal without worrying we're duplicating a thread buried three pages deep. Worth considering alongside the substantive request above. Happy to discuss the use case further or test a beta if this is something the team is open to exploring. Thanks for considering it, and apologies again to whichever poor soul at 1Password has to read the seventeenth version of this request.
