Observed
On a cloud-provisioned tenant environment (local prod-like stack at framework pin 8a96e666b, cloud chore/bump-objectstack-1934), every tenant kernel boot logs at ERROR level:
ERROR [auth] no_sign_in_account_at_boot: this deployment has human 'sys_user' rows but ZERO 'sys_account' rows — there is no credential, no federated link, no login of any kind, for anyone. NOBODY CAN SIGN IN, and the deployment CANNOT BE RECOVERED FROM INSIDE …
The reporter landed in objectstack#14866 (plugin-auth, changeset auth-no-sign-in-account-boot-report.md, "reports the zero-account boot dead end at kernel:ready").
Why it is a false alarm on this deployment shape
A cloud tenant environment has platform_sso_enabled = 1 and authenticates every human through the control plane's platform SSO handoff (/api/v1/cloud/environments/ID/sso-open → env /api/v1/auth/sso-exchange). The env-local user is created on first SSO and holds no sys_account credential row on purpose — cloud#1857 was closed on the maintainer ruling "tenant envs authenticate via platform SSO, no env-side auth mail". So the population the reporter counts (humans present, zero sys_account) is the NORMAL, healthy state of every tenant kernel, and the message's claim — "NOBODY CAN SIGN IN … CANNOT BE RECOVERED FROM INSIDE" — is wrong for it: the same boot served a full SSO handoff and an AI build turn a minute later.
Measured on the rig: the ERROR fired at 2026-09-03T20:03:52.990Z (the kernel rebuild after the AI publish), on an env where sign-in had just succeeded via SSO. It is the ONLY ERROR line in objectos.log for the whole smoke, so it reads as the one thing wrong with an otherwise clean boot.
Ask
Gate no_sign_in_account_at_boot on the deployment actually having no sign-in path: when platform SSO (or any federated provider that mints sessions without sys_account rows) is configured, the zero-account population is not a dead end and the report should not fire (or should degrade to a debug line naming the SSO path as the reason). The 2026-09-02 admission ruling (option A) is untouched — this is about the REPORT, not the carve-out.
Found while verifying cloud#1934 (framework pin bump to 8a96e666b); cloud PR carries the reading. Related: cloud#1857 (closed, SSO-only tenants), objectstack#14353 / #14866.
Generated by Claude Code
Observed
On a cloud-provisioned tenant environment (local prod-like stack at framework pin
8a96e666b, cloudchore/bump-objectstack-1934), every tenant kernel boot logs at ERROR level:The reporter landed in objectstack#14866 (
plugin-auth, changesetauth-no-sign-in-account-boot-report.md, "reports the zero-account boot dead end at kernel:ready").Why it is a false alarm on this deployment shape
A cloud tenant environment has
platform_sso_enabled = 1and authenticates every human through the control plane's platform SSO handoff (/api/v1/cloud/environments/ID/sso-open→ env/api/v1/auth/sso-exchange). The env-local user is created on first SSO and holds nosys_accountcredential row on purpose — cloud#1857 was closed on the maintainer ruling "tenant envs authenticate via platform SSO, no env-side auth mail". So the population the reporter counts (humans present, zerosys_account) is the NORMAL, healthy state of every tenant kernel, and the message's claim — "NOBODY CAN SIGN IN … CANNOT BE RECOVERED FROM INSIDE" — is wrong for it: the same boot served a full SSO handoff and an AI build turn a minute later.Measured on the rig: the ERROR fired at
2026-09-03T20:03:52.990Z(the kernel rebuild after the AI publish), on an env where sign-in had just succeeded via SSO. It is the ONLY ERROR line inobjectos.logfor the whole smoke, so it reads as the one thing wrong with an otherwise clean boot.Ask
Gate
no_sign_in_account_at_booton the deployment actually having no sign-in path: when platform SSO (or any federated provider that mints sessions withoutsys_accountrows) is configured, the zero-account population is not a dead end and the report should not fire (or should degrade to a debug line naming the SSO path as the reason). The 2026-09-02 admission ruling (option A) is untouched — this is about the REPORT, not the carve-out.Found while verifying cloud#1934 (framework pin bump to
8a96e666b); cloud PR carries the reading. Related: cloud#1857 (closed, SSO-only tenants), objectstack#14353 / #14866.Generated by Claude Code