[BUG] Claude Code may have mixed up MCP connections between parallel sessions, causing the agent in session 1 to use connection B instead of connection A.

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

issue on claude code desktop on mac using opus 4.8 max.
i continued working in a session and instructed the agent to keep the work that it was doing before and for that it used to connect to oracle atp via mcp (sqlcl) connection A.
in parallel i started another session and asked the agent to work using same mcp (sqlcl) using connection B.
after a while i found out on the first session conversation that its agent had used the oracle connection B - it found that by itself after having worked for sometime in the wrong oracle connection and had to undo work and redo it in the right connection.

<img width="982" height="564" alt="Image" src="https://github.com/user-attachments/assets/facb0025-a9a6-4ec8-9872-ccf6d9860291" />

What Should Happen?

claude should keep the oracle mcp connections separated for each claude session

Error Messages/Logs

ORA-00942 em todas as tabelas — inclusive ing_fontes e as GTTs que acabei de criar. Isso é o sintoma clássico de schema/privilégio: SQL avulso resolve via synonym/current_schema, mas a procedure (definer's rights) é criada no schema do usuário conectado e não enxerga as tabelas. Vou diagnosticar onde tudo vive:


Used 2 tools
Achado importante: estou conectado como FINHUB (não o owner do schema polbr), e o all_objects não mostra as tabelas do polbr pra esse user. Mas os SELECTs/CTAS anteriores funcionaram (juntando pessoas!). Duas hipóteses: (a) acesso via role → SQL funciona mas procedure definer's-rights não enxerga (ORA-00942 clássico), ou (b) a conexão trocou de sessão. Preciso diagnosticar com precisão:


Used 2 tools
Used sqlcl: run-sql
model: claude-opus-4-8
sql: SELECT USER AS u, (SELECT COUNT(*) FROM atos_normativos) AS atos FROM dual
Error starting at line : 1 in command -
SELECT /* LLM in use is claude-opus-4-8 */ USER AS u, (SELECT COUNT(*) FROM atos_normativos) AS atos FROM dual
Error at Command Line : 1 Column : 77
Error report -
SQL Error: ORA-00942: table or view "FINHUB"."ATOS_NORMATIVOS" does not exist

https://docs.oracle.com/error-help/db/ora-00942/00942. 00000 -  "table or view%s does not exist"
*Cause:    The specified table or view did not exist, or a synonym
           pointed to a table or view that did not exist.
           To find existing user tables and views, query the
           ALL_TABLES and ALL_VIEWS data dictionary views. Certain
           privileges may be required to access the table. If an
           application returned this message, then the table that the
           application tried to access did not exist in the database, or
           the application did not have access to it.
*Action:   Check each of the following
           - The spelling of the table or view name is correct.
           - The referenced table or view name does exist.
           - The synonym points to an existing table or view.

More Details :
https://docs.oracle.com/error-help/db/ora-00942/
Used sqlcl: list-connections
Agora ficou claro. Há várias conexões salvas (polbr, tw, fiap, finhub, polinex, …) — todas no mesmo ADB mas com usuários diferentes. Eu driftei para a conexão finhub (outro projeto!). Como FINHUB, atos_normativos realmente não existe (ORA-00942: "FINHUB"."ATOS_NORMATIVOS").

Isso significa que as GTTs + a proc que criei foram parar no schema FINHUB errado. Preciso: (1) reconectar firme no polbr, (2) limpar o lixo que deixei no FINHUB, (3) recriar tudo no polbr. Os SELECTs/CTAS/index anteriores funcionaram = estavam no polbr; só o trecho final driftou.

Vou reconectar no polbr e verificar o USER imediatamente:


Used 2 tools
Used sqlcl: connect
connection_name: polbr
model: claude-opus-4-8
### DATABASE CONNECTION ESTABLISHED ###
Successfully connected to: **polbr**
### DATABASE ENVIRONMENT CONTEXT ###
**1. Oracle Database Version:** 
23.26.2.2.0
Here’s the Oracle database context you need: version, open mode, and NLS parameters. Use this information to run the following queries accurately and ensure they align with the database’s current environment and settings.
Used sqlcl: run-sql
model: claude-opus-4-8
sql: SELECT USER AS u, (SELECT COUNT(*) FROM atos_normativos) AS atos,
       (SELECT COUNT(*) FROM user_objects WHERE object_name IN ('GTT_ASS_STAGE','GTT_ASS_MAP','CONSOLIDAR_ATOS_ASSINANTES_V2','IX_PESSOAS_NOME_NORM4')) AS meus_objs_aqui
  FROM dual
"U","ATOS","MEUS_OBJS_AQUI"
"POLBR",81526,2
Conectado como POLBR, atos_normativos OK (81.526), e 2 dos meus objetos-teste existem aqui. Preciso saber exatamente o quê está onde. Inventário preciso no POLBR:

Used sqlcl: run-sql
Esclarecido: as GTTs ficaram no POLBR (corretas), o índice foi dropado, e só a procedure foi parar no FINHUB (a conexão driftou entre chamadas — provavelmente reconecta num default após timeout). Estou confirmado como POLBR agora. Vou recriar a proc imediatamente e verificar que ficou no POLBR:

Used sqlcl: run-sql
Compilou sem erros! Vou confirmar que está VALID e no POLBR:

Steps to Reproduce

You're using Claude Code desktop on Mac with Opus 4.8
You had two parallel sessions with different MCP (sqlcl) connections (A and B)
Session 1's agent incorrectly switched to connection B instead of staying on connection A
The agent discovered the mistake itself and had to undo/redo work

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.108 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_