Testing auth emails in apps you build with Qoder

Why the email path needs a real check

Qoder’s agent is good at the code around authentication: forms, routes, token handling and email templates. But a change can pass every test and still send an email that links to localhost, never arrives because the sender isn’t set up, or contains a code that expires before anyone could type it. Those show up only when a real email reaches a real inbox.

Which login will it build?

Whichever you ask for, or the one your codebase already uses. Supabase Auth, Clerk, Firebase Authentication, Auth.js and Better Auth each send different emails: Clerk sends a code by default, Firebase a link, and Auth.js only magic links unless you build the rest. Name the methods you want in your request, then test each email the agent’s change sends. Which emails each login service sends.

Check it after every auth change

1. Run the app locally, or open the preview deployment for your branch.
2. Create an address in Proxy Mail QA, one per scenario: new user, invited user, password reset.
3. Go through the flow the change touched, using the code or link from the address’s row.
4. Read the whole email once in the inbox view: sender, subject, wording and every link.
5. Note what you found on the address, so it stays with the test account.

Links to localhost on a preview or staging deployment are flagged on the row. Here’s how to fix them in Supabase, Firebase, Auth.js and other stacks.

Let Qoder’s agent check the email itself

Add the Proxy Mail QA MCP server: open Qoder IDE Settings, choose MCP, then + Add on the My Servers tab, and add it under mcpServers:

{
  "mcpServers": {
    "proxymail-qa": {
      "type": "http",
      "url": "https://api.proxymail.qa/mcp"
    }
  }
}

Save it, and sign in to Proxy Mail QA in your browser when asked, choosing the project the agent may use. Set Qoder’s permission level to Ask every time, not Auto approve, and approve each Proxy Mail QA step when Qoder asks: under Auto approve, the agent may not find the tools and suggest the marketplace instead. Then ask in plain words: “Sign up on localhost:3000 with a new Proxy Mail QA address and confirm the email.” The agent creates the address, fills in your form, waits for the code or link and finishes the sign-up. Other ways to connect, including an API key, are in MCP server setup.

Copy-paste prompts for Qoder

List every email this app sends: sign-up confirmation, magic link, password reset, invite and email change. For each, show where it's triggered in the code, which service sends it, how its link URL is built, and how long its code or link is valid. Flag hard-coded localhost URLs.

Build every link in auth emails from an environment variable for the app's public URL, with localhost only as the development default. Add the variable to .env.example and the deployment settings.

The email says the code is valid for 10 minutes. Make the server enforce the same expiry, and make requesting a new code invalidate the old one.

A rule that prevents the usual bugs

Give the agent this rule, in your project’s rules or at the start of an auth task, so it follows it whenever it touches auth:

When changing sign-up, login, password reset, invites or any email-sending code:
- Build links from the app's public URL setting, never a hard-coded localhost.
- Keep the expiry stated in an email equal to the one the server enforces.
- Make single-use links and codes stop working once used or replaced.
- Tell me which emails to test by hand after the change.