Skip to content
Chiho AI
Start for FreeLog in
← Back to Blog
Telegram MCPAccount IdentitySource Evidence

Use the Right Telegram Account When Two Chats Have the Same Name

Chris · Chiho•Published 18 Oct 2026
Use the Right Telegram Account When Two Chats Have the Same Name

When two Telegram chats have the same name, choose the intended account and resolve the conversation to a scoped peer before asking AI to read it. A matching title is a clue, not proof of identity. Keep the account, personal or team context, peer type and identifier together with each cited message.

Chiho supplies authorized existing Telegram account conversations to AI clients such as Codex, Claude, and ChatGPT. A bot or channel that carries instructions to an agent is a different use case; that connection alone does not establish access to a personal conversation archive. Account identity, applicable Business permissions, documented tools and actual history coverage determine access. See the Telegram MCP architecture guide.

Published by Chiho. Product statements checked against source on 18 October 2026. This is a suggested verification workflow and fictional exercise, not a live-account test. The header image shows general Chiho interface context, not this identity check.

Identify the account before choosing the conversation

Start with Chiho MCP setup, complete browser authorization and inspect the current connection's tools. Call auth_status to check the authenticated scope, then account_whoami to inspect the accessible Telegram accounts. Authentication success alone does not select the intended Telegram account.

The current identity response includes account identifiers and connection or reauthentication status. Personal account display names can be absent; team responses do not provide those display names. Do not invent a friendly label when the returned context is insufficient. Confirm the intended account with the authorized user, privately, before reading conversation content.

For current inventory tools, an omitted accountId is rejected when more than one healthy account is available. Carry the chosen account explicitly wherever the advertised schema supports it. Do not rely on the primary-account flag as a permanent routing choice.

Resolve the peer rather than guessing from its title

Use dialogs_list for the authorized personal account, or crm_dialogs_list for the available team CRM scope. Current team-scoped connections do not offer the personal dialogs_list path. Where supported, includeLastMessage: false requests metadata without latest-message previews. Page within the agreed boundary; one page is not the whole account.

Inspect the returned peer identifier and kind, alongside the title. Preserve a returned peerRef when available and accepted by the next tool. Do not construct a descriptor by copying a number from another account or changing the peer kind. Account context and peer type matter even when identifiers or names look familiar.

The current scoped-title resolver rejects an exact title when it matches multiple peers in that scope. Numeric peer lookup can also be ambiguous without account and kind context. Treat an ambiguity error as a request to resolve the target, not permission to pick the first match. A unique match still needs the reader's intent check: it could be the wrong “Launch” conversation.

The chat inventory guide explains why live dialogs and saved CRM rows can differ. A missing CRM row does not establish that a conversation does not exist; do not start synchronization or widen account access silently to resolve it.

Keep identity attached to every source

Before chat_read, state the verified account and scope, resolved conversation and intended question. Use the advertised schema for account selection, peer, any supported peerRef, limit and continuation. Request only the messages needed. Do not run concurrent history reads against the same account; honor a returned wait before another read.

Keep this compact source receipt in the authorized workspace:

  • Connection context: environment, personal or team scope, and selected account routing identifier.
  • Conversation: title for readability, peer identifier and kind, and returned descriptor where needed.
  • Evidence: message identifiers, original timestamps, retrieval time and relevant excerpts.
  • Coverage: intended period, actual returned span, continuation or stopping boundary, and missing material.

This is a suggested report format, not a new Chiho API object. Do not put access hashes, credentials or private account details in public reports. A message number alone is insufficient context for a citation. If the account or scope changes, resolve the target again and keep the new result separate. The conversation comparison guide shows how to retain separate source packets.

Try a same-name collision without customer data

Use these fictional cards locally. The labels are deliberately not executable tool arguments.

Synthetic identity cards — not live Telegram output or tool arguments
DEMO-IDENTITY | all names, identifiers and messages are fictional
A: account WORK-A | scope personal | title Launch | peer channel:7101
   message 401 | 2026-10-16 09:00 +08:00 | Wait for legal review.
B: account WORK-B | scope personal | title Launch | peer channel:7102
   message 401 | 2026-10-16 09:00 +08:00 | Internal rehearsal approved.
C: account WORK-A | scope personal | title Launch | peer chat:7103
   message 402 | 2026-10-16 09:05 +08:00 | Design review tomorrow.
Requested source: WORK-A / channel:7101 / message 401
Expected conclusion: legal review is pending; approval is not established.
Coverage: these supplied cards only; no live reads or complete archive claim.

Ask the client which statement supports approval in the requested conversation. It should select card A and report pending legal review. Card B's approval concerns a different account and purpose; card C has the same account and title but a different peer. The repeated message number does not connect the sources.

Now remove the requested peer from the exercise. The correct next step is to clarify which WORK-A conversation is intended, not combine A and C. This is an acceptance protocol you can repeat, not a measured accuracy result or evidence of live tool behavior.

Stop at the boundary when scope does not match

A team grant covers its authorized team context, not every personal conversation belonging to a teammate. Current team history routing checks the scoped dialog and its Telegram session owner. An outside-scope response or reauthentication request needs resolution in that context; switching to a personal token is not an automatic fallback.

Keep a source read separate from a later task or message request. Chiho applies action-specific permissions and safeguards, and clients control their tool prompts; not every write requires an extra approval. This prompt intentionally requests only a read:

Verify the connection and intended Telegram account. Resolve [conversation] within that scope. If names collide or identity remains unclear, stop and ask me to choose using metadata first. Read at most [limit] messages for [question and period] using the advertised schema. Return the answer with account/scope/peer/message references and actual coverage. Keep other accounts and chats separate. Do not synchronize, edit CRM records, create tasks or send messages.

Finish with one identifiable source-backed answer

A useful answer names the resolved conversation, gives a conclusion supported by its messages, and makes coverage limits visible. If the identity is unresolved, return the missing identity check instead of a confident summary from a similar chat.

Connect Chiho MCP, authorize in the browser, verify identity and perform one bounded read. Review the source receipt before separately requesting a follow-up action.