AI-Context/MCP usa caminhos fora do container e fica inconsistente em Dev Container no VS Code

[wandersonkd]

Ao usar o AI-Context dentro de um Dev Container/Docker no VS Code, o MCP não se comporta como se estivesse preso ao filesystem do container. Mesmo inicializando o contexto com repoPath apontando para /workspace, as respostas do MCP continuam serializando caminhos como C:\workspace.context e, em alguns casos, ainda preservam caminhos antigos do host Windows.

Além disso, há divergência entre o estado retornado pelas ferramentas do MCP e os arquivos reais dentro do workspace do container. Isso faz parecer que parte do estado está sendo lida de uma localização fora do container, ou de um cache paralelo, em vez de usar exclusivamente os arquivos presentes em /workspace/.context.

Ambiente

• VS Code com Dev Container
• Container Linux
• Workspace montado em /workspace
• Host original Windows
• Ferramentas usadas: AI-Context via MCP

Passos para reproduzir

1. Abrir o projeto dentro de um Dev Container, com workspace em /workspace.
2. Inicializar o AI-Context com repoPath em /workspace.
3. Consultar o estado com as ferramentas de contexto e workflow.
4. Comparar os caminhos e conteúdos retornados pelo MCP com os arquivos reais dentro de /workspace/.context.

Comportamento observado

1. O MCP retorna outputDir como C:\workspace.context, mesmo com o projeto rodando dentro do container Linux e o repoPath definido como /workspace.
2. O workflow-status retorna statusFilePath como C:\workspace.context\workflow\status.yaml, mas o arquivo real status.yaml no container está vazio.
3. Mesmo com status.yaml vazio, o workflow-status continua retornando um workflow ativo e coerente, o que indica que a fonte de verdade não é esse arquivo local.
4. O histórico em actions.jsonl preserva caminhos antigos do host Windows, como d:\Projetos\UltraSeven\GitHub\UltraSevenAngular\ultrawebngx.
5. O conteúdo local de project-overview.md contém a raiz antiga do Windows, enquanto algumas chamadas do MCP retornam um currentContent diferente para o mesmo arquivo.
6. Chamadas como getMap retornam análise claramente incorreta para o repositório aberto, por exemplo:
   • totalFiles: 1
   • totalSymbols: 0
   • hasDocker: false
     Isso não bate com o workspace real aberto em /workspace.
7. Chamadas como listToFill e fillSingle retornam caminhos no formato C:\workspace.context..., embora os arquivos reais estejam dentro de /workspace/.context.

Comportamento esperado

1. Ao rodar dentro de Dev Container, o AI-Context deve usar exclusivamente caminhos do container, por exemplo /workspace/.context.
2. O workflow-status deve refletir o arquivo real dentro do container, especialmente status.yaml.
3. O conteúdo retornado por fillSingle, check, listToFill e workflow-status deve ser consistente com os arquivos reais do workspace.
4. O getMap deve analisar o repositório real montado no container, não um contexto vazio/parcial ou um cache externo.
5. Caminhos antigos do host não deveriam ser reutilizados automaticamente quando o contexto é reinicializado no container.

Impacto

• Gera dúvida sobre qual é a fonte real do estado do workflow.
• Faz parecer que o MCP está lendo fora do container ou usando cache externo invisível.
• Complica debugging, automação e confiança no estado do AI-Context.
• Pode induzir agentes a trabalhar com documentação, mapas e workflows inconsistentes com o código real aberto no container.
• Dificulta reset limpo do contexto quando o projeto migra do host para Dev Container.

Evidências observáveis

• status.yaml: arquivo local vazio, mas workflow-status retorna workflow ativo.
• actions.jsonl: histórico ainda aponta para caminho do host Windows.
• project-overview.md: raiz do projeto ainda aparece como caminho antigo do Windows.
• O MCP retorna outputDir e statusFilePath em formato Windows mesmo após init com repoPath igual a /workspace.

Suspeita técnica
Parece haver pelo menos uma destas falhas:

1. O AI-Context normaliza ou serializa caminhos usando lógica de Windows mesmo dentro de container Linux.
2. O estado do workflow/contexto está sendo lido de um storage externo ao workspace do container.
3. Existe cache persistente por usuário/sessão sendo priorizado sobre os arquivos reais do diretório .context do projeto.
4. O processo de reinit com repoPath em /workspace não invalida corretamente o estado anterior do host.
5. As rotinas de leitura de mapa/documentos e workflow não compartilham a mesma fonte de verdade.

Sugestões de correção

1. Garantir que, em ambiente containerizado, o repoPath e o outputDir sejam resolvidos exclusivamente a partir do filesystem do container.
2. Unificar a fonte de verdade do workflow para os arquivos reais dentro de .context do workspace.
3. Invalidar caches antigos quando o repoPath mudar entre host e container.
4. Expor no retorno das ferramentas de onde o estado foi lido:
   • caminho real
   • cache/session store
   • workspace file
5. Corrigir a detecção de plataforma para que o MCP não devolva caminhos Windows quando estiver rodando em Linux/container.
6. Adicionar um modo de reset completo do contexto que limpe referências antigas de host.

[vinilana]

Hi @wandersonkd we will add a fix for this to our roadmap for version 0.8+