The sync seeds each member's gateway key into LibreChat's per-user key store, but it can only seed a user that already exists — and LibreChat creates that row on first login. Ten minutes therefore left a new member's very first message to fail against a key-less endpoint. At one minute the window is at most 60 seconds. Zero would mean patching LibreChat's login path, which is not worth a fork for this.
The key is auto-seeded within 10 minutes of first login by sync-keys.js, but a new user's first screen is the API-keys panel, which reads as mandatory. The welcome line is the surface we control; the settings dialog builds its strings from templates in a component chunk with no en locale bundle, so it is not cleanly patchable. Option 1 of three in the issue, approved by the GM.
LibreChat's PluginAuth schema keys on a string userId; Key (the chat key
collection) is ObjectId-typed and Mongoose casts for it. The seeder used
`user._id` (an ObjectId) for BOTH, so every MCP auth row it wrote was
invisible to PluginService.getUserPluginAuthValue():
string lookup -> 0 rows (what the app does)
ObjectId lookup-> 1 row
Consequence: userMCPAuthMap['mcp_inference-image'] was empty for every
member, ToolService skipped the server ("missing user configuration"), and
any agent expecting MCP tools failed with
AgentToolInitializationError: "The agent is configured to use MCP tools, but
none are available" — 7 times since Oct 19, most recently 2026-10-27 22:29.
The image-generation MCP server (generate_image) was unavailable to everyone.
The docs server was unaffected (it declares no customUserVars).
Fix: String(uid) in the two pluginauths upserts only. The keys[] upserts are
deliberately left as ObjectId — chat key lookup works and changing it would
break the working half.
Verified: 54 existing rows migrated ObjectId -> string (backup at
/app/data/backup-pluginauths-userid-2026-10-27T2239Z.json), all 55 image rows
now string-typed, the app-style string lookup returns a row, and a full
seeder run passes its own decrypt guard and encrypt/decrypt round-trip check
(54 seeded, 17 skipped).
With enforce: true (in place since at least Oct 23), every send whose body
carries no `spec` is rejected by api/server/middleware/buildEndpointOption.js
with "No model spec selected", surfaced to members as "Inference Co-op could
not complete this request."
400 of 547 conversations across 37 users had no `spec` — all created before
the spec system (newest Oct 20). They fail on the members' first send;
new chats were fine because the softDefault spec pre-selects.
enforce: false lets those conversations send with their own stored model
exactly as before Oct 20. prioritize stays true, so the spec picker is still
the primary chooser — it is just no longer mandatory. Verified: the change is
read at boot (no watcher in the image), so the app was restarted; the served
stylesheet md5 is unchanged by the restart; the mirror is byte-identical to
the deployed file (sha256 219dbdf2ca0b64f8…). Backup of the previous config
stays on the volume as /app/data/librechat.yaml.bak-20261027T221149Z.
If enforcement is ever restored, backfill `spec` on those conversations first,
mapping by each conversation's own `model` (only exact matches — a mismatch
triggers "Model spec mismatch" instead).
The release chain read the tag back from CloudronManifest.json BEFORE pinning
it, so t was always the previous tag: release built the new image, then
deployed the old one and printed success — the exact silent no-op this script
exists to prevent. Its usage text promises build -> pin -> deploy -> verify;
it did build -> deploy.
cmd_build now exports the tag it built and release pins THAT, then deploys and
verifies. Not exercised end-to-end yet (the theme deploy that found this bug
was run as separate build/pin/deploy steps and passed all checks); the edit is
syntax-checked only.
Follow-up to the custom.css/custom2.js change: the Dockerfile seds the web
manifest theme_color/background_color and the index.html light meta to
#eaf3ea, and the README's verify block asserted the green wash as correct
("an earlier version of this block asserted cream ... would have led you to
fix a correct deploy"). Both are the same regression: the wash was rejected
earlier, restored by accident, and then documented as intended.
- Dockerfile: manifest + index meta -> #faf8f5 (cream), with an explicit
"keep these three in sync" note (this sed, custom.css html:not(.dark),
custom2.js COOP_BG.light).
- README verify block: asserts cream again, plus a new step for the
install-time colors no DOM check covers (manifest + light meta).
- README palette section: hover is #f0ede6 not the wash; --presentation is
cream; source of truth is the DEPLOYED CSS of dashboard/portal/panel, with
the read command; records the shared 4.32:1 / 3.93:1 accessibility caveat;
notes that cloudron exec silently swallows multi-line sh -c.
v3 used the green wash #eaf3ea for --surface-primary, the page background,
which read as too green. Replaced with the palette read from the DEPLOYED
CSS of the dashboard, portal and panel (identical across all three):
--surface-primary #eaf3ea -> #faf8f5 (cream, page background)
--surface-tertiary green -> #f4f2ec (warm chip)
--surface-hover green -> #f0ede6 (warm hover)
--surface-composer-hover -> #f0ede6
--border-light #cde0cb -> #e4e0d8 (warm neutral border)
--presentation #eaf3ea -> #faf8f5 (composer band)
--link #4a7a4a -> #4e7a4d (deeper green, 4.70:1 on cream)
Accents are unchanged (green-deep #5b8c5a, green-mid #6ba86b) — they are
the earthy greens the co-op design system already uses. Dark mode is
untouched. Also fixed the two hard-coded washes: the #loading-container
flash and the bare html/body background, plus custom2.js COOP_BG.light,
which was still painting the browser/PWA chrome #eaf3ea while the
manifest said cream.
inference-bot