The export, not the file. SDODS looks for steps/auth.ts, steps/auth.js or auth.ts under the project root, imports whichever it finds first, and takes the auth named export or the default export — but only accepts it if it has a login function on it. A module that exports a plain config object, or exports the class instead of an instance, does not match, and you fall through to the yaml strategy. For custom there is nothing to fall through to, hence the error.
So the fix is usually one line in that file. A full example:
Return the context and stop there — SDODS saves the storage state off it and closes it. Once that resolves, --user works for the recorder and for the runner, because both read the same cached file.
Credentials come off the pool row on user, so nothing in that file is a literal.
One thing to check before you write any of that: if your login is interactive — a second factor, a consent screen, anything a script cannot get through — you do not want custom at all. Declare sso and capture the state with a person in the loop:
bash
sdods auth capture -p demo-shop -e staging -u standard --interactive
That opens codegen, waits for you to finish the login, and saves the storage state.
Rough rule: custom is for logins you can automate, sso is for the ones you cannot.