You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit f360d80
Browse filesBrowse the repository at this point in the historyBrowse files
An unsuffixed `TELEGRAM_EXPECTED_USERNAME` applies to every account that has no
595
-
suffixed value. When neither is set (the default) no check is made and no extra
596
-
request is sent.
573
+
Set `TELEGRAM_EXPECTED_USERNAME` (or `TELEGRAM_EXPECTED_USERNAME_<LABEL>` per account) and the server refuses to start when the session belongs to a different account. The comparison is case-insensitive and ignores a leading `@`. Unset means no check.
597
574
598
575
## Proxy Support
599
576
@@ -867,10 +844,8 @@ Telegram messages, display names, chat titles, and button labels are untrusted c
867
844
the MCP server when you can scan from an existing Telegram app, or
868
845
`uv run session_string_generator.py --phone` when you need phone-code login.
869
846
Then set `TELEGRAM_SESSION_STRING` in `.env`. The MCP server does not perform
870
-
interactive phone-code login over stdio. This also applies when a session is
871
-
terminated (for example from **Settings > Devices** on another device) while the
872
-
server is running: the next reconnect fails with "not authorized after reconnect"
873
-
instead of prompting for a phone number. Re-authorize as above and restart the server.
847
+
interactive phone-code login over stdio, including after a reconnect: a session
848
+
terminated while the server runs fails with "not authorized after reconnect".
874
849
-**Invalid API credentials:** verify `TELEGRAM_API_ID` and `TELEGRAM_API_HASH` at [my.telegram.org/apps](https://my.telegram.org/apps).
875
850
-**Database is locked:** make sure no other process is using the same file session.
876
851
-**`AuthKeyDuplicatedError` / "Another telegram-mcp process is already connected with this session":** two processes tried to connect the same Telegram session at once (e.g. an MCP client restarted the connector before the old process exited), which Telegram rejects and can invalidate the session for both. The server now takes an exclusive lock per session before connecting; a second concurrent launch waits briefly (default 20s, override with `TELEGRAM_LOCK_GRACE_SECONDS`) for the first to release it and otherwise exits without ever calling `connect()`, instead of racing into a duplicate connection. Retry once only one instance is running — the refusal names the PID holding the lock. If several instances on this host are meant to share one session (all reaching Telegram from the same IP), set `TELEGRAM_SESSION_LOCK=shared`; see [Sharing one session from one host](#sharing-one-session-from-one-host).
0 commit comments