Help Me Write AI - a copilot assistant for your browser
At times, we all need to compose messages for others, and many of us turn to chatbots to enhance the correctness, professionalism, or appeal of our writing. Correcting grammar and syntax errors is crucial for both business and personal communications.
As specialists in developing browser extensions, our team chose to eliminate the need for external chatbot applications while utilizing Gmail and Google Docs. We initially created a basic extension for internal use, and then someone proposed incorporating recipes (saved prompts and context) to tailor texts for individual users.
After refining and enhancing the tool, we decided to publicly launch Help Me Write AI, inviting others to give it a try.
Help Me Write AI lets you select text in any editable field — emails, docs, support tools, forms, CRMs, or social posts — and apply AI-powered recipes to transform it in one click.
It’s built for universal use across the web, but with a powerful custom twist:
recipes = prompt + context, so your results stay consistent and useful for your specific use cases and tasks — your tone, brand voice, role, audience, product details, and more.
How it works:
Select text in any input field (or highlight text on the page)
Pick a recipe (Rewrite / Fix / Translate / Expand / Summarize / Custom)
Auto-applies your Prompt + Context and either replaces the selected text instantly or shows the result in the overlay so you can copy/insert it when ready
Smart move building this as an extension instead of another standalone AI editor. Removing friction inside Gmail and Docs is strong positioning.
From a security perspective, browser extensions come with unique risks, so I’m curious:
• What permissions are you requesting in the manifest? Are you limiting host permissions to only necessary domains, or is it broad
<all_urls>access?• How are you handling selected text before sending it to the model? Is everything processed server-side through your backend, or does the extension call the AI API directly?
• Are you logging or storing user content for improvement, or is it strictly transient?
Since the extension can access content inside CRMs, support tools, and email drafts, being explicit about data flow, storage, and API key handling will be critical for trust.
A short “How we protect your text” section on the site could make a big difference in adoption.
Totally agree - and thanks for calling it out.
Security + trust are top-priority for us. This is the first release, so right now we’re intentionally optimizing for low friction (fast onboarding, minimal setup, quick UX feedback), but we’re already planning tighter controls as we harden the product.
Here are the answers:
- Manifest permissions / host access:
Today we request <all_urls>. The reason is simple: the extension is designed to work “anywhere you write”, and we didn’t want users to hit “it doesn’t work on X” in week one.
That said, we understand this is the biggest red flag for reviewers and security-minded teams, and we’re actively working toward more restrictive host permissions + clearer UX around what the extension can read and when.
- How selected text is handled / data flow:
The extension builds the final prompt locally (user prompt + recipe + selected text) and then sends a request to our API backend, which acts as a proxy for authentication + usage counting + routing to different LLM providers.
We’re also considering an “advanced mode” where users can call the AI provider directly from the extension if they bring their own API key — so the text never goes through our proxy.
- Logging / storage:
We do not log or store user content. We only track usage metrics (counts/limits), not the text itself.
Product improvements are driven mostly by what we learn from our own daily usage and by iterating on the recipes/prompts (that’s the part that changes behavior). The server is mainly for proxying + provider routing, not content retention.
You’re also 100% right about messaging: a short “How we protect your text” section is on our list, and we’ll make the data flow + API key handling explicit (especially for people using it inside CRMs/support/email drafts).
Appreciate the transparent answer. That context helps.
Requesting <all_urls> for usability is understandable early, but you’re right, that’s the biggest trust friction point. Moving toward narrower host permissions or clearly scoped activation will reduce hesitation for security-conscious users.
Browser extensions operate inside highly sensitive environments like Gmail and CRMs. Clear, visible boundaries will directly impact adoption.
Congrats on the launch, looks solid. How are you currently thinking about acquiring early users and gathering feedback?