A read-only mode that wraps SPHttpClient still sends e-mail — Graph is a second channel

Symptom

You add a preview/read-only mode, verify it by trying to save a list item (correctly refused), and ship. Later someone notices e-mail going out from a session that was supposed to write nothing — an approval notification, a reminder, a "task assigned" message. The list stayed untouched, so nothing in SharePoint hints at what happened.

The same hole covers anything routed through Graph: creating a Planner task, adding a calendar event, patching a group.

Cause

The wrapper is a choke point for exactly one transport:

// blocks writes — for SharePoint only
function readOnlySpClient(real) {
  return {
    get:   (u, c, o) => real.get(u, c, o),
    post:  (u, c, o) => ALLOWED_READ_POSTS.test(u) ? real.post(u, c, o) : Promise.reject(new Error(MSG)),
    fetch: (u, c, o) => ((o?.method || 'GET').toUpperCase() === 'GET' || ALLOWED_READ_POSTS.test(u))
      ? real.fetch(u, c, o) : Promise.reject(new Error(MSG))
  };
}

MSGraphClient doesn't go through it. It's built from context.msGraphClientFactory, holds its own token and its own HTTP stack — a service doing client.api('/me/sendMail').post(...) is invisible to the code above.

Fix

Wrap every write-capable client, not just the SharePoint one. For Graph, the muted version should return the value the callers already handle for "sending failed" — but build it by subclassing the real service, not by casting an object literal to its type:

// mail service used by views; in read-only mode it just reports failure
export class MutedMailService extends GraphMailService {
  public async send(): Promise<boolean> { return false; }   // callers already handle false
}

const mail = readOnly ? mutedMail : realMail;

⚠️ The obvious shortcut rots silently. The tempting version is a literal with the one method you need, cast into place:

function readOnlyMail(): GraphMailService {
  const stub = { send: () => Promise.resolve(false) };
  return stub as unknown as GraphMailService;   // ← don't
}

as unknown as T is a double assertion — it switches off every structural check, so the compiler never compares what the stub implements against what T promises. It is correct the day you write it and decays with the next method added to the service. Six months later notifyDecision() exists, views call it, the read-only path throws notifyDecision is not a function, and neither the compiler nor the linter nor the build says a word. Worse, it only fires in the mode nobody routinely clicks through. Subclassing makes the compiler enforce the contract for you; Object.create(real) with a single overridden method is the other safe shape, because everything you didn't override survives on the prototype chain. Keep double assertions for real instances and for data (DTOs, style objects, the shape of a dynamic import()) — never to fake behaviour you haven't written.

Two things worth doing while you're there:

• Enumerate the outbound channels once, in the shell. Grep the app for msGraphClientFactory, fetch(, axios, navigator.sendBeacon and any SDK client. Each one is a separate hole; the list is short and it doesn't change often.
• Watch for silent write side effects on read paths. View counters, "last opened" stamps and telemetry rows are writes too — in a preview they leave a trace that says the wrong person opened something.

Verifying it

Don't test the mode by clicking Save — a disabled button proves nothing about the layer underneath. Reach the client the views actually receive (in React, via the fiber on your root node) and issue a write to a harmless URL:

await ctx.spHttpClient.post(webUrl + '/_api/web/DOES_NOT_EXIST', {}, { headers: {} })
// wrapper working  → rejected locally, no request leaves the browser
// wrapper bypassed → HTTP 404 from SharePoint (it reached the server)

The difference between "rejected by the client" and "404 from the server" is what tells you the choke point is real. Repeat for the Graph path with whatever your app's send/create call is, on a target you own.