Yes, LinkedIn is a verified working site, and also the most caveated one, because LinkedIn runs three different composer surfaces and one of them gets special handling. Short version: everything works in comments; the share composer gets everything except the inline agent; messaging works with a small undo caveat.
The three LinkedIn surfaces
| Surface | Editor | What works |
|---|---|---|
| Share composer (new post) | Quill | Blanks, transforms, word cues; single-entry undo via Quill's own API. Inline agent disabled here. |
| Comment boxes | Quill | Everything, including agentically ... _ tasks. |
| Messaging composer | Generic contenteditable path | Fills and rewrites work; undo takes multiple steps rather than one. |
Why the share composer has no inline agent
Quill's internal cursor doesn't resync from browser selections set after a programmatic write, so after a background agent-rewrite tick, your next keystroke could land at the wrong position. Typing into the wrong place is worse than losing the feature, so the extension reports the share composer as not supporting agent rewrite and the runtime declines to arm tasks there. The detection is deliberately narrow: an earlier version disabled the agent on every Quill editor and silently broke LinkedIn comments; it now targets only the share composer. One-shot substitutions (translate to japanese _, weather _, transforms, word cues) are unaffected because their cursor position is computed deterministically from the substituted span.
Undo and styling honesty
In the share composer, writes go through Quill's own text API as a single operation, so Ctrl+Z is one step. In messaging, the write path produces one undo entry per internal command, so reverting a fill can take several Ctrl+Z presses; the repo documents this as a known trade-off. And as on most managed editors, make X bold _ usually doesn't render on LinkedIn: the markers are stripped so your text stays clean, but the editor's schema decides whether bold appears.
Practical LinkedIn uses
Drafting posts with a rewrite pass (make this more formal _), replying to comments with the agent watching spelling, and identity-context fills (my github _) for profile-adjacent writing all fit naturally. The extension never attaches to password or payment fields anywhere on the site.
Related: The Chrome extension · What is an inline agent? · OpenCues on Gmail · OpenCues on Notion · GitHub repo