You maintain two profiles: a personal assistant and a team bot, each with its own Telegram or Feishu bot. At 3am, the team bot’s scheduled job finishes — and the result is delivered from your personal bot instead. Or worse, delivery fails with Bot not in chat: the job succeeded, but nobody ever saw the result. A fix merged on August 31 (PR #99375) digs this whole class of cross-talk out by the root: which bot delivers a cron job’s message is decided by the profile that owns the job — not by whatever process happened to execute it.

The root cause: delivery identity followed the wrong “person”

In Hermes’ multi-profile design, every profile has its own config, credentials, session database, and messaging bots. But before this fix, cron delivery had a fatal flaw: delivery identity followed the executing process instead of the job’s owner profile.

Concretely: you start the gateway from your main profile, and it hosts profile B’s jobs along the way. When B’s job runs, the system reads “the current process’s” credentials — which belong to the main profile — so B’s result goes out via the main profile’s bot. Delivering to B’s group chat? The bot is not in that group, so it errors. Delivering to the main profile’s chat? The message lands in the wrong place. The job succeeded, yet the result vanished.

And that was only half of it. cron status had a matching lie: it treated any live profile’s gateway as proof of health — even when profile B’s own scheduler was not running at all. The status looked green while B’s jobs would never fire.

The fix: four root causes, one principle

PR #99375 cherry-picks nine contributors’ commits and fixes each link in this chain, under one principle: delivery identity must come from the job’s owning profile. Concretely:

• Each profile’s tick gets its own adapter map: when multiplexing (_start_multiplex), every profile’s tick receives its own platform adapter map; shared adapters are reserved for the default profile only and never serve as a fallback for unconnected secondary profiles;
• The profile secret scope now spans delivery: previously the scope was reset right after the job ran, so standalone-send fallbacks resolved the executing process’s platform tokens; now the scope covers _deliver_result end to end;
• Home chat IDs resolve from the owning profile’s secrets: target chat id / thread id are resolved via get_secret under the owning profile’s scope instead of raw environment variables;
• Profile jobs write sessions into their own state.db: the SessionDB is constructed through contextvars.copy_context(), so B’s cron runs stop persisting sessions into the default profile’s database;
• Satellite-profile preflight rescue: satellites routed through gateway.profile_routes read the primary config directly, fail closed, and leak no environment;
• cron status tells the truth: systemd PID discovery is scoped to this profile’s service name, and a never-seen heartbeat reads as a warning, not green.

How to verify on your machine

After updating to latest main, first check that your profile’s scheduler status is now trustworthy:

# Status for one profile's own scheduler — not a "any gateway is alive" green light
hermes -p work cron status

Then run a cron job with delivery and watch whether the message comes from that profile’s own bot and lands in that profile’s home chat. For anyone running multiple profiles across multiple platforms, this is an immediately visible experience fix: results no longer vanish, cross-talk is gone, and “job succeeded but nobody received it” ghost messages stop.

When you can use it

PR #99375 merged on August 31, 2026 and is on main only — not yet in a release. It fixes a cluster of real user reports: #94862, #97909, #99028, #98790, #97476 — all “message never arrived” / “status is lying” complaints.

Multiple profiles are one of Hermes’ most underrated capabilities: each profile gets its own identity, memory, and bots. To use them well, start with our complete multi-profile guide and Feishu multi-profile routing; the full cron playbook lives in the cron automation complete guide.