Arquitetura do Sistema

Stack de Comunicação

O Claude Desktop (Electron) utiliza uma arquitetura de dois processos onde o renderer (SPA) nunca faz chamadas HTTP diretas. Toda comunicação de rede passa pelo main process (Node.js).

+------------------------------------------------------------------+
|                    CLAUDE DESKTOP (Electron)                       |
|                                                                    |
|  +------------------+     IPC ($eipc_message$)     +-----------+  |
|  |   RENDERER (SPA) |<---------------------------->|   MAIN    |  |
|  |   (WebView)      |  via contextBridge + preload |  PROCESS  |  |
|  |                   |                              | (Node.js) |  |
|  | - UI/UX           |   invoke/on/sendSync         |           |  |
|  | - Voice (WebAPI)  |                              | - HTTP    |  |
|  | - MCP (IPC call)  |                              | - FS I/O  |  |
|  | - Session State   |                              | - Child   |  |
|  |                    |                              |   Process |  |
|  +------------------+                               | - BLE/Ser |  |
|       |                                              | - TCC    |  |
|       | window.claudeAppBindings                     +-----------+  |
|       | window.electronWindowControl                     |         |
|       | window.electronIntl                              |         |
|       | window.buddyBle                           ANTHROPIC_BASE_URL|
|       +---(preload bridge)---ipcRenderer.invoke-->   |         |
|                                                        |         |
|                                            +------------v------+ |
|                                            |  LITELLM GATEWAY   | |
|                                            | (localhost:4000)   | |
|                                            +--------------------+ |
|                                                      |            |
|                                           +----------v--------+   |
|                                           |  ANTHROPIC API    |   |
|                                           | api.anthropic.com |   |
|                                           +-------------------+   |
+------------------------------------------------------------------+

Mecanismos HTTP do Main Process

O main process utiliza quatro mecanismos HTTP distintos dependendo do tipo de requisição:

Mecanismo	Uso	Detalhes
`electron.net.fetch` (`oA.net.fetch`)	API first-party	OAuth, bootstrap, environments, files, organizations
`axios` (`JyA`)	CLI-facing	Code sessions, bridge credentials, worker register
`electron.net.request` (`oA.net.request`)	Telemetria	OTLP batch event logging
`fetch()` nativo do Node	Model probing	Chamadas de proxy, health checks

Resolução de URL Base

ANTHROPIC_BASE_URL (env) -> this.apiHost

Prioridade	Fonte	Exemplo
1	`process.env.ANTHROPIC_BASE_URL`	`https://api.anthropic.com`
2	Store override	Store key `apiHost`
3	Default	`https://api.anthropic.com`

Variáveis Internas de Resolução

Variável	Resolução	Exemplo
`ji()`	`app.getURL()`	`https://claude.ai` (ou localhost dev)
`this.apiHost`	`ANTHROPIC_BASE_URL`	`https://api.anthropic.com`
`uF()`	Config endpoint	`https://api.anthropic.com`
`n.apiHost` (OAuth)	OAuth issuer	`https://api.anthropic.com`
`api_base_url` (bridge)	Bridge service	`https://bridge.claudeusercontent.com`
`audio_proxy_url`	Audio service	`https://audio.anthropic.com`

Hierarquia de Classes do SDK

class Yg (base API resource)
  ._client.post(path, options)
  ._client.get(path, options)
  ._client.delete(path, options)
  ._client.getAPIList(path, type, options)

class kh extends Yg (SDK root)
  models: u_t             -> GET /v1/models, GET /v1/models/{id}
  messages: WAe            -> POST /v1/messages, count_tokens, batches
  agents: VAe              -> POST/GET/POST/DELETE /v1/agents/*
  environments: c_t        -> POST/GET/POST/DELETE /v1/environments/*
  sessions: VmA            -> POST/GET/POST/DELETE /v1/sessions/*
  vaults: jAe              -> POST/GET/POST/DELETE /v1/vaults/*
  memoryStores: qmA        -> POST/GET/POST/DELETE /v1/memory_stores/*
  files: I_t               -> GET/POST/DELETE /v1/files/*
  skills: $Ae              -> POST/GET/DELETE /v1/skills/*
  userProfiles: E_t         -> POST/GET/POST /v1/user_profiles/*

Principios de Comunicação

O renderer NUNCA faz chamadas HTTP diretas. Toda comunicação de rede passa pelo main process.
O main process usa três mecanismos HTTP distintos dependendo do tipo de chamada (electron.net.fetch, axios, electron.net.request).
Voice é processado 100% no renderer (Web APIs: MediaRecorder, getUserMedia). Zero IPC envolvido.
MCP é gerenciado pelo main process (child processes para servidores MCP). Renderer comunica via IPC.
Feature flags são injetadas via argumentos de linha de comando OU via IPC para AppConfig.

Conexões em Tempo Real

Conexão	URL Pattern	Tipo	Propósito
Messages Stream	`POST /v1/messages` (com `stream: true`)	SSE	Streaming de resposta do modelo
Bridge Worker Events	`{api_base_url}/v1/code/sessions/{id}/worker/events/stream`	SSE -> WS Upgrade	Transporte bidirecional para code sessions
Bridge WebSocket	`wss://bridge.claudeusercontent.com`	WS	Conexão persistente bridge
Session Events	`GET /v1/sessions/{id}/events/stream?beta=true`	SSE	Stream de eventos de sessão
Voice WebSocket	`/api/ws/voice/...` ou `/v1/b`	WS	Audio full-duplex
MCP Server Transport	Transporte local (stdio)	STDIO	Comunicação com servidores MCP locais

Stack de Comunicação​

Mecanismos HTTP do Main Process​

Resolução de URL Base​

Variáveis Internas de Resolução​

Hierarquia de Classes do SDK​

Principios de Comunicação​

Conexões em Tempo Real​