Problem
Agent sandboxes with strict egress policies (e.g. Claude Code Cloud routines / CCR environments) commonly allow outbound traffic only to a small fixed allowlist of hosts — package registries, the platform's own APIs, and traffic routed through the platform's managed MCP proxy. Direct outbound HTTPS calls from the hotdata CLI to api.hotdata.dev are not on that allowlist and get rejected at the network layer before reaching Hotdata at all:
error connecting to API: error sending request for url (https://api.hotdata.dev/v1/databases/...)
[agent-proxy] connect_rejected (the egress proxy denied the CONNECT (organization policy) or could not reach the destination)
This makes it impossible to use Hotdata from inside these sandboxes at all, regardless of API key validity — confirmed this is a network-policy block, not an auth issue, by checking the sandbox's own egress-proxy status endpoint.
Why other integrations aren't affected
Google/HubSpot-style integrations in these sandboxes work fine because their traffic goes through the platform's own MCP connector proxy, not raw outbound HTTPS initiated by the CLI. MCP connector traffic is pre-approved by design; arbitrary third-party API traffic is not.
Feature request
Give Hotdata an alternate transport that goes through this same trusted path — most concretely, an official Hotdata MCP server that can be registered as an MCP connector (comparable to how Gmail/HubSpot connectors work in Claude's ecosystem, and likely equivalent connector mechanisms in other agent platforms). If Hotdata exposes its read/write operations (databases, tables, query) as MCP tools, agent sandboxes could reach Hotdata over the already-trusted connector path instead of raw CLI/API egress, sidestepping this whole class of network-policy blocks.
Evidence
Reproduced 4/4 times on 2026-09-07 from a Claude Code Cloud routine (env_01VtnYFmhfbnP7L1TDMDVbDy), sessions cse_01NnDSTPcRXvHM3ATEpkvGHv, cse_0164WMKoTxVhUsEwZjqxmPnc, cse_01BufC55gg5TPjUKSi8ikZvY, cse_015Wnn8caCPZAe3fFzrLbcov. Filed the corresponding platform-side bug against Claude Code's egress-allowlist limitation at anthropics/claude-code#92706 — this issue is the Hotdata-side complement: even if that gets fixed for Claude specifically, other agent platforms with similar sandboxing will hit the same wall unless Hotdata offers a transport that doesn't depend on arbitrary outbound HTTPS being allowed.
Problem
Agent sandboxes with strict egress policies (e.g. Claude Code Cloud routines / CCR environments) commonly allow outbound traffic only to a small fixed allowlist of hosts — package registries, the platform's own APIs, and traffic routed through the platform's managed MCP proxy. Direct outbound HTTPS calls from the
hotdataCLI toapi.hotdata.devare not on that allowlist and get rejected at the network layer before reaching Hotdata at all:This makes it impossible to use Hotdata from inside these sandboxes at all, regardless of API key validity — confirmed this is a network-policy block, not an auth issue, by checking the sandbox's own egress-proxy status endpoint.
Why other integrations aren't affected
Google/HubSpot-style integrations in these sandboxes work fine because their traffic goes through the platform's own MCP connector proxy, not raw outbound HTTPS initiated by the CLI. MCP connector traffic is pre-approved by design; arbitrary third-party API traffic is not.
Feature request
Give Hotdata an alternate transport that goes through this same trusted path — most concretely, an official Hotdata MCP server that can be registered as an MCP connector (comparable to how Gmail/HubSpot connectors work in Claude's ecosystem, and likely equivalent connector mechanisms in other agent platforms). If Hotdata exposes its read/write operations (databases, tables, query) as MCP tools, agent sandboxes could reach Hotdata over the already-trusted connector path instead of raw CLI/API egress, sidestepping this whole class of network-policy blocks.
Evidence
Reproduced 4/4 times on 2026-09-07 from a Claude Code Cloud routine (
env_01VtnYFmhfbnP7L1TDMDVbDy), sessionscse_01NnDSTPcRXvHM3ATEpkvGHv,cse_0164WMKoTxVhUsEwZjqxmPnc,cse_01BufC55gg5TPjUKSi8ikZvY,cse_015Wnn8caCPZAe3fFzrLbcov. Filed the corresponding platform-side bug against Claude Code's egress-allowlist limitation at anthropics/claude-code#92706 — this issue is the Hotdata-side complement: even if that gets fixed for Claude specifically, other agent platforms with similar sandboxing will hit the same wall unless Hotdata offers a transport that doesn't depend on arbitrary outbound HTTPS being allowed.