Escolha a conta certa do Telegram quando dois chats têm o mesmo nome

Quando dois chats do Telegram têm o mesmo nome, escolha a conta desejada e resolva a conversa para um peer no escopo autorizado antes de pedir uma leitura à IA. Um título igual é uma pista, não uma prova de identidade. Mantenha conta, contexto pessoal ou de equipe, tipo e identificador do peer junto de cada mensagem citada.

O Chiho fornece conversas existentes de contas Telegram autorizadas a clientes de IA como Codex, Claude e ChatGPT. Um bot ou canal que leva instruções a um agente atende a outro uso; essa conexão, por si só, não comprova acesso ao arquivo pessoal. Identidade da conta, permissões Business aplicáveis, ferramentas documentadas e cobertura real do histórico determinam o acesso. Veja o guia de arquiteturas Telegram MCP.

Publicado pelo Chiho. Afirmações do produto conferidas no código em 18 de outubro de 2026. Este é um fluxo sugerido e um exercício fictício, não um teste com conta real. A imagem mostra o contexto geral da interface, não esta verificação.

Identifique a conta antes de escolher a conversa

Comece pela configuração do Chiho MCP, conclua a autorização no navegador e consulte as ferramentas atuais. Use auth_status para verificar o escopo autenticado e account_whoami para examinar as contas Telegram acessíveis. Autenticação bem-sucedida não seleciona a conta pretendida.

A resposta atual inclui identificadores e estado de conexão ou necessidade de nova autenticação. Nomes de exibição pessoais podem estar ausentes; respostas de equipe não fornecem esses nomes. Quando faltar contexto, não invente um rótulo: confirme a conta em privado com o usuário autorizado antes de ler conteúdo.

As ferramentas atuais de inventário rejeitam a ausência de accountId quando há várias contas conectadas saudáveis. Informe explicitamente a conta escolhida onde o esquema anunciado permitir. Não trate a marca de conta principal como escolha permanente de roteamento.

Resolva o peer em vez de adivinhar pelo título

Use dialogs_list para a conta pessoal autorizada ou crm_dialogs_list para o escopo CRM de equipe disponível. Conexões de equipe atuais não oferecem o caminho pessoal dialogs_list. Quando aceito, includeLastMessage: false solicita metadados sem prévias da última mensagem. Percorra páginas dentro do limite acordado; uma página não representa toda a conta.

Confira identificador e tipo do peer além do título. Preserve o peerRef retornado se estiver disponível e a próxima ferramenta o aceitar. Não monte um descritor copiando um número de outra conta ou alterando seu tipo. Conta e tipo importam mesmo quando nomes ou números parecem familiares.

O resolvedor atual de títulos exatos rejeita correspondências com vários peers no escopo. A busca por número também pode ser ambígua sem conta e tipo. Um erro de ambiguidade pede resolução do destino, não a escolha do primeiro resultado. Até uma correspondência única exige conferir a intenção: pode ser outra conversa “Launch”.

O guia de inventário explica por que diálogos ao vivo e linhas CRM salvas podem divergir. Uma linha ausente não prova que a conversa não existe. Não inicie sincronizações nem amplie acesso silenciosamente.

Mantenha a identidade junto de cada fonte

Antes de chat_read, informe conta e escopo verificados, conversa resolvida e pergunta. Siga o esquema anunciado para conta, peer, eventual peerRef, limite e continuação. Solicite apenas mensagens necessárias. Não leia históricos simultaneamente na mesma conta e respeite a espera retornada antes de outra leitura.

Guarde uma ficha curta no espaço autorizado:

• Conexão: ambiente, escopo pessoal ou de equipe e identificador da conta selecionada.
• Conversa: título legível, identificador e tipo do peer, descritor retornado quando necessário.
• Evidência: identificadores das mensagens, horários originais, horário de recuperação e trechos relevantes.
• Cobertura: período pretendido, intervalo recebido, continuação ou limite de parada e material ausente.

É um formato sugerido de relatório, não um novo objeto da API. Não publique access hashes, credenciais ou detalhes privados da conta. Um número de mensagem isolado não basta. Se conta ou escopo mudar, resolva o destino novamente e separe os resultados. O guia de comparação de conversas mostra como manter pacotes de fontes distintos.

Experimente uma colisão com dados fictícios

Use os cartões localmente. Nomes, identificadores e mensagens são fictícios; os rótulos não são argumentos executáveis. WORK indica conta, personal indica escopo pessoal e channel/chat são tipos distintos. A pede aguardar revisão jurídica; B aprova um ensaio interno; C anuncia revisão de design amanhã.

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.

Pergunte qual afirmação comprova aprovação na conversa solicitada. O cliente deve escolher A e informar que a revisão jurídica está pendente. A aprovação de B pertence a outra conta e outra finalidade; C tem a mesma conta e título, mas outro peer. O número repetido da mensagem não conecta as fontes.

Depois remova o peer solicitado. O próximo passo correto é esclarecer qual conversa de WORK-A se pretende, não combinar A e C. É um protocolo de aceitação repetível, não precisão medida nem evidência de chamadas reais.

Pare quando o escopo não corresponder

Uma autorização de equipe cobre o contexto de equipe permitido, não todas as conversas pessoais de um colega. O roteamento atual do histórico da equipe verifica o diálogo e o dono da sessão Telegram. Uma recusa de escopo ou pedido de reautenticação deve ser resolvido nesse contexto; trocar para um token pessoal não é uma alternativa automática.

Separe a leitura de uma solicitação posterior de tarefa ou mensagem. O Chiho aplica permissões e proteções por ação, e os clientes controlam seus avisos; nem toda escrita exige aprovação extra. Este pedido solicita apenas leitura:

Verifique a conexão e a conta Telegram pretendida. Resolva [conversa] nesse escopo. Se os nomes coincidirem ou a identidade estiver incerta, pare e peça que eu escolha primeiro pelos metadados. Leia no máximo [limite] mensagens para [pergunta e período], usando o esquema anunciado. Retorne resposta, referências de conta/escopo/peer/mensagem e cobertura real. Separe outras contas e chats. Não sincronize, edite CRM, crie tarefas ou envie mensagens.

Termine com uma resposta de fonte identificável

Uma resposta útil identifica a conversa resolvida, apresenta uma conclusão apoiada nas mensagens dela e deixa claros os limites de cobertura. Se a identidade continuar indefinida, indique a verificação que falta em vez de resumir com confiança um chat parecido.

Conecte o Chiho MCP, autorize no navegador, verifique a identidade e faça uma leitura delimitada. Revise a ficha de fontes antes de pedir outra ação separadamente.