Login fails: 'object is not a function' in the OAuth encrypt path (getPublicKeyThumbprint → encrypt) — fresh/re-login blocked

[proggeramlug]

Hit in live manual testing of cc_manual @ f6aac9e5c4 (macOS aarch64, sandboxed HOME=/tmp/sbs_home_p). Onboarding ran (theme picker), then cc asked to log in, and the login fails:

ERROR object is not a function

  at Lw5 (<anonymous>)
  at WN8.calculateLayout (<anonymous>)
  at get destination (<anonymous>)
  at ZT8 (<anonymous>)
  at getPublicKeyThumbprint (<anonymous>)
  at encrypt (<anonymous>)
  at new hy6__class_expr_7524 (<anonymous>)
  at YNY (<anonymous>)
  at da7.add (<anonymous>)
  at BtY (<anonymous>)

After the error the process is idle-parked (verified: CPU delta 0.01 s over 10 s; sample shows 3510/3513 main-thread samples in kevent), so this is a hard failure of the login flow, not a hang.

Severity: blocks first-time and re-login. An already-authenticated sandbox HOME works fine — earlier the same binary ran a full authenticated session — so the broken path is specifically the login/token-encryption flow, which the 196-case stress suite cannot reach (it runs unauthenticated by design).

The real frames

getPublicKeyThumbprint and encrypt are the meaningful ones: cc encrypts the OAuth token for storage. Something in that path resolves to a non-callable — the #9485 shape (a native-module method that answers undefined without throwing, so the call is what fails) is a prime suspect; likely candidates are crypto.subtle/webcrypto exports (importKey, exportKey, digest, encrypt) or a node:crypto namespace method reached in a spelling perry's dispatch doesn't cover. Worth checking against #9498's fix (CJS-default namespace method calls) — the same drifted-table class could leave a different module's methods unreachable.

Second finding: the stack names are mis-attributed

WN8.calculateLayout is the bundle's pure-JS yoga replacement (identified in the binary census) and get destination/da7.add are unrelated — a layout call cannot be between ZT8 and a crypto thumbprint. This is #9521's documented limitation in the field: "an address inside a function codegen emits but does not name borrows the preceding name". Two consequences: (a) don't trust the middle frames of this trace when debugging, and (b) it argues for the Tier-2 work (or at least denser name registration) since frame names are now load-bearing for exactly this kind of report.

Repro path

Fresh sandbox HOME (no .credentials.json), run the binary, complete onboarding, choose login. Compare against node cli_2.1.112.js in an identical fresh HOME — if node completes the same login, the divergence is perry-side and the failing call is isolatable by instrumenting the crypto dispatch. Evidence sample: /Users/amlug/projects/perry/wedge-9590/authfail_sample.txt.

[proggeramlug]

Caution before closing this against PR #9679.

#9679 (nine unrooted Array.prototype callbacks) is real, independently proven — a PERRY_GC_PROTECT_FROMSPACE=1 fault on a retired GC_TYPE_CLOSURE at js_array_forEach + 4072, gone after — and it is a documented producer of exactly this error string. But its link to this issue was never confirmed at cc level: the investigating agent's credential-free repro completed the whole OAuth path breadcrumb-identically to node, so the login firing was never reproduced.

New evidence that weakens the attribution further: on a branch already rebased onto main including #9679, object is not a function still fires — during onboarding, at WN8.calculateLayout (filed as #9701). So either there is a second site of the same class, or a different cause produces this string.

Recommendation: keep this open until a cc-level retest on a build containing #9679 — i.e. a real login attempt on a fresh HOME. If it succeeds, close against #9679; if it still fails, the trace (ideally from a --debug-symbols build, which puts at <file>:<line> in the message) will say whether it is the same family at a new site or something else entirely.