[Bug]: Hermes Gateway Crashes/Fails to Poll Inbound Telegram Messages with separate Bots on Named Profiles

### Bug Description ## Describe the bug When attempting to run a secondary named profile (`bff`) with its own isolated Telegram bot alongside a `default` profile, the background messaging gateway fails to process or respond to inbound Telegram updates in a private 1-on-1 DM. Despite the Desktop UI or terminal indicating a successful "Connected" state, incoming updates trigger an immediate, silent background failure. This manifests as a visual "Connected" -> "Connecting" loop refresh in the Desktop UI, indicating that the gateway daemon crashes and attempts a hard restart the exact moment a payload is delivered. The application suffers from severe cross-profile leakage, token lock retention, visual UI state desynchronization, and unhandled data-type schema validation crashes when handling user tracking arrays across `.env` and `config.yaml` files. ### Steps to Reproduce ## Steps To Reproduce (Granular Step-by-Step Chronology), use the attempt descriptions below and run the following with each change: ```bash hermes gateway stop ``` ```bash hermes gateway start --profile bff ``` _or whatever profile name you're testing with_. **Attempt 1: Initial Setup via UI** - **Action**: Created a secondary Telegram messaging service on a separate profile using separate bot tokens via the Desktop UI. - **Result**: Both profiles encountered a hard lock showing a red `Messaging Gateway Stopped` pill. The default profile locked the machine's local messaging network port, blocking the second profile from binding its routing service. **Attempt 2: UI Menu Navigation & CLI Process Kill** - **Action**: Navigated to the default profile's **Command Center->Gateways** menu to stop its daemon. Discovered no "Stop" mechanism exists under that menu sub-item. Executed `hermes gateway stop` in the terminal to clear the background lock, then ran `hermes doctor` to fix broken system hooks. - **Result**: Successfully cleared the visual `Messaging Gateway Stopped` pill from the default profile. However, switching to the secondary profile in the UI left its status indicator stuck on a red "Stopped" pill due to a front-end status polling bug. **Attempt 3: Terminal Profile Switching (`hermes profile use`)** - **Action**: Switched profiles via the terminal using `hermes profile use bff`, then switched the active visual profile inside the desktop application sidebar. - **Result**: The red `Messaging Gateway Stopped` pill successfully vanished from the UI. However, the Telegram bot remained entirely silent and completely unresponsive to any inbound user interaction. **Attempt 4: Direct CLI Token Assignment (`hermes config set`)** - **Action**: Discovered token leakage in the logs: `ERROR gateway.platforms.base: [Telegram] Telegram bot token already in use by the 'default' profile`. Attempted to isolate tokens via CLI tools using `hermes config set platforms.telegram.bot_token` for each profile respectively, followed by purging stale lock assets using `rm -rf` over the local state gateway-locks directory. - **Result**: The target setup command threw syntax/structure errors, revealing that Hermes does not store active Telegram bot tokens inside the core `config.yaml` file layout. **Attempt 5: Manual `.env` Isolation & String Formatting** - **Action**: Manually populated individual hidden files: `~/.hermes/.env` (default token) and `~/.hermes/profiles/bff/.env` (secondary token) using `TELEGRAM_BOT_TOKEN`. Configured the numeric Telegram User ID allowlist inside the `.env` utilizing string-enclosed brackets: `TELEGRAM_ALLOWED_USERS="[USERID]"`. Retained a mirroring fallback block in `config.yaml` where the `USERID` did not have square brackets: ```yaml platforms: telegram: enabled: true allowed_users: [USERID] ``` - **Result**: Running `hermes gateway setup` indicated Telegram was configured, but the bot remained unresponsive. Testing the local engine processing layer independently via `hermes chat -q "reply with ok"` successfully returned `"ok"` in the terminal, meaning the LLM engine was functional while the Telegram parsing loop remained frozen. **Attempt 6: Remote Webhook Flashing & Context Isolation** - **Action**: Evaluated if the token was stuck in webhook mode. Executed a direct API command to Telegram's master routing database: `curl -X POST "https://api.telegram.org/bot<token>/deleteWebhook?drop_pending_updates=true"`. Switched profile context and forced an explicit background service launch by executing `hermes gateway start --profile bff`. - **Result**: Telegram confirmed `Webhook was already deleted`, meaning long-polling was active. The bot remained unresponsive. **Attempt 7: Global Security Bypass & Array Restructuring** - **Action**: Commented out the `TELEGRAM_ALLOWED_USERS` variable entirely inside both profile `.env` files to prevent string-parsing errors. Added a global bypass parameter to the `.env`: `GATEWAY_ALLOW_ALL_USERS=true`. Restructured the `config.yaml` block to parse the user ID as an explicit list item: ```yaml platforms: telegram: enabled: true allowed_users: - [USERIDs] ``` Attempted to clear the app's cache registry via `hermes gateway clean` before starting. - **Result**: `hermes gateway clean` threw a terminal exception and failed to run. Starting the gateway via `hermes gateway start --profile bff` resulted in a **runtime crash loop**. The service showed "Connected" in the UI, but sending a `/start` command caused the UI status to immediately fail, drop back to "Connecting", recover to "Connected", and fail again upon a secondary text submission. Current state of _config.yaml_ in both Default and bff profiles is as shown above. Current _.env_ files have the following entries: ``` TELEGRAM_BOT_TOKEN=8...I GATEWAY_ALLOW_ALL_USERS=true ``` ### Expected Behavior When launching a named profile with the explicit runtime path flag (`--profile bff`), the gateway daemon should cleanly isolate all platform parameters without fallback cross-contamination. Upon receiving an inbound private 1-on-1 update payload, the underlying Python parsing engine should gracefully ingest user metadata, seamlessly evaluate the list object or respect the `GATEWAY_ALLOW_ALL_USERS` validation bypass, and complete the text generation transaction without crashing the core thread pool. Any ideas on how to achieve this? ### Actual Behavior Bot remains unresponsive in all attempts described in Steps to Reproduce. ### Affected Component Gateway (Telegram/Discord/Slack/WhatsApp) ### Messaging Platform (if gateway-related) Telegram ### Debug Report ```shell Report https://paste.rs/jckag agent.log https://paste.rs/EJFJu gateway.log https://paste.rs/z76C1 gui.log https://paste.rs/EdjWq ``` ### Operating System Tahoe 26.5.2 (25F84) ### Python Version 3.12.3 ### Hermes Version Hermes Agent v0.20.4 (2026.8.18) · upstream 1c4dc4cf ### Additional Logs / Traceback (optional) ```shell ``` ### Root Cause Analysis (optional) _No response_ ### Proposed Fix (optional) _No response_ ### Are you willing to submit a PR for this? - [ ] I'd like to fix this myself and submit a PR