Elige la cuenta correcta de Telegram cuando dos chats se llaman igual

Cuando dos chats de Telegram tienen el mismo nombre, elige primero la cuenta y resuelve la conversación a un peer dentro del ámbito autorizado antes de pedirle a la IA que lea. Un título coincidente es una pista, no una prueba de identidad. Conserva la cuenta, el contexto personal o de equipo, el tipo y el identificador del peer junto a cada mensaje citado.

Chiho proporciona conversaciones existentes de cuentas de Telegram autorizadas a clientes de IA como Codex, Claude y ChatGPT. Un bot o canal que envía instrucciones a un agente sirve para otro uso; esa conexión por sí sola no acredita acceso al archivo personal. La identidad de la cuenta, los permisos Business aplicables, las herramientas documentadas y la cobertura real del historial determinan el acceso. Consulta la guía de arquitecturas Telegram MCP.

Publicado por Chiho. Afirmaciones del producto contrastadas con el código el 18 de octubre de 2026. Es un flujo recomendado y un ejercicio ficticio, no una prueba con cuentas reales. La imagen muestra contexto general de la interfaz, no esta comprobación.

Identifica la cuenta antes de elegir la conversación

Empieza por la configuración de Chiho MCP, completa la autorización en el navegador y consulta las herramientas actuales. Usa auth_status para comprobar el ámbito autenticado y account_whoami para revisar las cuentas de Telegram accesibles. La autenticación correcta no selecciona por sí misma la cuenta deseada.

La respuesta actual incluye identificadores y estado de conexión o necesidad de volver a autenticar. Los nombres visibles de cuentas personales pueden faltar; las respuestas de equipo no proporcionan esos nombres. Si falta contexto, no inventes una etiqueta: confirma la cuenta en privado con el usuario autorizado antes de leer contenido.

Las herramientas actuales de inventario rechazan la omisión de accountId si hay varias cuentas conectadas en buen estado. Lleva la cuenta elegida explícitamente donde el esquema anunciado lo permita. No dependas de la marca de cuenta principal como decisión permanente de enrutamiento.

Resuelve el peer en vez de adivinar por el título

Usa dialogs_list para la cuenta personal autorizada o crm_dialogs_list para el ámbito CRM de equipo disponible. Las conexiones de equipo actuales no ofrecen la ruta personal dialogs_list. Cuando se admita, includeLastMessage: false solicita metadatos sin vistas previas del último mensaje. Pagina dentro del límite acordado; una página no es toda la cuenta.

Revisa identificador y tipo de peer además del título. Conserva el peerRef devuelto si está disponible y la siguiente herramienta lo acepta. No construyas un descriptor copiando números de otra cuenta o cambiando el tipo. El contexto de cuenta y el tipo importan aunque el nombre o número resulte familiar.

El resolvedor actual de títulos exactos rechaza coincidencias con varios peers en el ámbito. Una búsqueda numérica también puede ser ambigua sin cuenta y tipo. Un error de ambigüedad exige resolver el destino, no elegir el primer resultado. Incluso una coincidencia única requiere confirmar la intención: podría ser otro chat «Launch».

La guía de inventario explica las diferencias entre diálogos en vivo y filas CRM guardadas. Una fila ausente no demuestra que no exista la conversación. No inicies sincronizaciones ni amplíes el acceso silenciosamente.

Adjunta la identidad a cada fuente

Antes de chat_read, indica cuenta y ámbito verificados, conversación resuelta y pregunta. Sigue el esquema anunciado para cuenta, peer, cualquier peerRef compatible, límite y continuación. Solicita solo los mensajes necesarios. No hagas lecturas de historial simultáneas en la misma cuenta y respeta la espera devuelta antes de repetir.

Conserva una ficha breve en el espacio autorizado:

• Conexión: entorno, ámbito personal o de equipo e identificador de la cuenta elegida.
• Conversación: título legible, identificador y tipo de peer, descriptor devuelto cuando haga falta.
• Evidencia: identificadores de mensajes, fechas originales, hora de recuperación y fragmentos pertinentes.
• Cobertura: periodo solicitado, intervalo recibido, continuación o límite de parada y material ausente.

Es un formato recomendado de informe, no un nuevo objeto API. No publiques access hashes, credenciales ni detalles privados de cuentas. Un número de mensaje aislado no basta. Si cambian cuenta o ámbito, vuelve a resolver el destino y separa los resultados. La guía de comparación de conversaciones explica cómo mantener paquetes de fuentes separados.

Prueba una colisión con datos ficticios

Usa estas tarjetas localmente. Todos los nombres, identificadores y mensajes son ficticios; las etiquetas no son argumentos ejecutables. WORK identifica la cuenta, personal el ámbito y channel/chat tipos de peer distintos. A dice que se espere la revisión legal; B aprueba un ensayo interno; C anuncia revisión de diseño mañana.

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.

Pregunta qué afirmación respalda la aprobación en la conversación solicitada. El cliente debería elegir A e informar que la revisión legal está pendiente. B pertenece a otra cuenta y a otro propósito; C comparte cuenta y título, pero tiene otro peer. El número de mensaje repetido no une las fuentes.

Elimina después el peer solicitado. El siguiente paso correcto es aclarar qué conversación de WORK-A se busca, no combinar A y C. Es un protocolo de aceptación repetible, no una medición de precisión ni evidencia de llamadas reales.

Detente si el ámbito no coincide

Un permiso de equipo cubre su contexto autorizado, no todas las conversaciones personales de un compañero. El enrutamiento actual del historial de equipo verifica el diálogo y el propietario de la sesión Telegram. Un rechazo por ámbito o una petición de reautenticación se resuelve en ese contexto; cambiar a un token personal no es una alternativa automática.

Separa la lectura de una petición posterior de tarea o mensaje. Chiho aplica permisos y protecciones por acción, y los clientes controlan sus avisos; no toda escritura exige una aprobación adicional. Esta petición solicita solo lectura:

Verifica la conexión y la cuenta Telegram deseada. Resuelve [conversación] en ese ámbito. Si coinciden nombres o falta identidad, detente y pídeme elegir primero con metadatos. Lee como máximo [límite] mensajes para [pregunta y periodo] según el esquema anunciado. Devuelve respuesta, referencias de cuenta/ámbito/peer/mensaje y cobertura real. Mantén separados otros chats y cuentas. No sincronices, edites CRM, crees tareas ni envíes mensajes.

Termina con una respuesta de fuente identificable

Una respuesta útil nombra la conversación resuelta, presenta una conclusión apoyada en sus mensajes y muestra los límites de cobertura. Si no se ha resuelto la identidad, explica la comprobación pendiente en lugar de resumir con seguridad un chat parecido.

Conecta Chiho MCP, autoriza en el navegador, verifica la identidad y realiza una lectura acotada. Revisa la ficha de fuentes antes de solicitar otra acción por separado.