What causes "No screen access granted" in hcengineering/platform?

Add the sender address as 'from' in the request body.

hcengineering/platform · error · Error

No screen access granted

Error message

No screen access granted

What it means

The mail service endpoint in services/mail/pod-mail/src/main.ts responds with HTTP 400 and { err: "'from' is missing" } when the send-mail request body lacks the 'fromAddress' sender field. It is the last of handleSendMail's required-field checks; reaching it means text/html, subject, and to were all present but 'from' was absent. The service needs 'from' to build the SendMailOptions passed to the underlying mail transport.

Source

Thrown at desktop/src/ui/screenShare.ts:44

    return
  }

  if (navigator.mediaDevices.getDisplayMedia === undefined) {
    throw new DeviceUnsupportedError('getDisplayMedia not supported')
  }

  navigator.mediaDevices.getDisplayMedia = async (opts?: DisplayMediaStreamOptions): Promise<MediaStream> => {
    if (opts === undefined) {
      throw new Error('opts must be provided')
    }

    const ipcMain = ipcMainExposed()
    const sources = await ipcMain.getScreenSources()

    const hasAccess = await ipcMain.getScreenAccess()
    if (!hasAccess) {
      log.error('No screen access granted')
      throw new Error('No screen access granted')
    }

    return await new Promise<MediaStream>((resolve, reject) => {
      let wasSelected = false

      showPopup(
        love.component.SelectScreenSourcePopup,
        {
          sources
        },
        'top',
        () => {
          if (!wasSelected) {
            reject(new Error('No source selected'))
          }
        },
        (val) => {
          if (val != null) {

View on GitHub (pinned to 63e28dc964)

Solutions

Add the sender address as 'from' in the request body.
If the app has a system sender, configure it (e.g. MAIL_FROM env var) and inject it server-side into every request.
Fail fast at startup if the configured sender address is missing rather than at send time.
Centralize payload construction in one helper that always sets 'from'.

Example fix

// before
const body = { to, subject, text, from: process.env.MAIL_FROM } // env unset -> undefined dropped
// after
const from = process.env.MAIL_FROM
if (!from) throw new Error('MAIL_FROM is not configured')
const body = { to, subject, text, from }

Defensive patterns

Strategy: validation

Validate before calling

const from = process.env.MAIL_FROM
if (!from) throw new Error('MAIL_FROM is not configured; cannot send mail')

Type guard

function hasSender(body: unknown): body is { from: string; [k: string]: unknown } {
  return typeof body === 'object' && body !== null && typeof (body as any).from === 'string' && (body as any).from.length > 0
}

Try / catch

const res = await fetch(mailUrl, { method: 'POST', body })
if (res.status === 400) {
  const { err } = await res.json()
  if (err === "'from' is missing") {
    // abort with a configuration error — this payload can never succeed as-is
  }
}

Prevention

Configure a default system sender via env var and validate it at service startup, not at send time.
Centralize 'from' injection in a single request-builder helper.
Add a smoke test that sends to a mail trap in staging to catch missing sender config early.

When it happens

Trigger: POSTing to the mail endpoint with body content, subject, and 'to' but no 'from' property, or 'from' set to undefined/null.

Common situations: A service account or sender address configured via env var that is unset in the deployment; refactored callers that dropped the 'from' field; default-sender logic that silently yields undefined.

Related errors

AI-assisted analysis of hcengineering/platform@63e28dc964 (2026-08-29). Data as JSON: /api/errors/cd770346435ac719. Report an issue: GitHub.