Schedule Tasks + MCP

[pedrojreis]

In my instance i've several MCPs setted up. The main one I use are the microsoft ones (Teams, Outlook, etc) - we leverage OPENID_REUSE_TOKENS so that the mcps automatically login from our authentication.

Said that i'd like to use Schedule Tasks to give me a daily brief using said MCPs, but it seems that when ran via Scheduled tasks i constantly have a 401, but if i manually refresh the same chat all goes well.

Am I missing something here? :)

[ECD5A]

One thing that may explain the difference is the credential context.

A normal chat has a browser session that can refresh OpenID credentials, while a scheduled run is unattended and cannot complete an interactive OAuth flow. Because of that, OPENID_REUSE_TOKENS=true may be enough for interactive chat but still result in a 401 for the scheduled MCP call.

I would first check whether the 401 happens during MCP readiness/preflight or only when tools/call starts. Then compare:

• the MCP auth mode: direct {{LIBRECHAT_OPENID_ACCESS_TOKEN}}, OBO, or MCP OAuth;
• the token expiry, audience, and scopes;
• whether the same agent works after refreshing the OpenID session.

For Entra/Graph, it is also worth checking offline_access, the LibreChat API scope, and the delegated Graph scopes.

The relevant documentation is here:

• https://www.librechat.ai/docs/features/scheduled_chats
• https://www.librechat.ai/docs/features/mcp
• 🍵 fix: Support Renewable MCP Credentials for Schedules #15908
• 🪪 feat: Pass Schedule Identity to MCP Token Providers #15962

If you share a redacted log excerpt showing where the 401 occurs, it should be possible to tell whether this is an expired/unavailable scheduled credential or an audience/scope/OBO mismatch. Just make sure not to include bearer tokens or a raw HAR file.

[pedrojreis]

i can confirm that Entra has the offline_access scope :)

I'll take a look at the logs and try to bring more information!

[pedrojreis]

After some more search i got some facts that makes this fail to work:

• user.federatedTokens is request-scoped, never persisted. processOpenIDAuth in api/strategies/openidStrategy.js calls updateUser(...) first, then returns { ...user, tokenset, federatedTokens: {...} }. openIdJwtStrategy.js rebuilds it per-request from req.session?.openidTokens. A scheduled run loads the user via methods.findUser({_id: id}) — no tokens attached.

• Failure is silent, not stripped. resolveGraphTokenPlaceholder logs No valid OpenID token available for Graph token exchange and returns the string unchanged. And packages/api/src/utils/env.ts explicitly excludes {{LIBRECHAT_GRAPH_ACCESS_TOKEN}} from the strip-to-empty pattern. So the literal secret goes on the wire → Graph 401.

• Retry works because it's an interactive request with the session.

Basically It would be needed for LChat to store an entra refresh token per user in a durable vault or pass that to the MCP.

Also, in here one can read :
"LibreChat resolves OpenID credentials for MCP and Microsoft Graph from the live session, coordinates refreshes across replicas, and fences logout so a late refresh cannot recreate a signed-out session"

So it's basically by design that we don't have this feature :(

Unless i'm missing something

[ECD5A]

Your trace of the missing session context checks out. Scheduled MCP preflight loads the user from the database, so it doesn't inherit the request-scoped federatedTokens.

One nuance in the PRs I linked: #15908 lets a host supply renewable credentials for scheduled OBO calls, and #15962 passes the schedule, owner, and server context to that provider. Neither PR adds a credential store or provider to the default app. So with only the live OpenID session, I don't see a configuration-only fix for unattended Graph calls.

The unresolved {{LIBRECHAT_GRAPH_ACCESS_TOKEN}} is a placeholder string, not a leaked credential. Logs would still be needed to tell where the 401 occurs, but the missing scheduled credential looks like the core issue. A maintainer could confirm whether a built-in provider is planned.