dagger/dagger · error
client %q already exists with different host service proxy c
Error message
client %q already exists with different host service proxy client %q
What it means
When an existing initialized client is reattached with a HostServiceProxyClientID that differs from the one already recorded, the server rejects the request. A client's host-service proxy binding must be stable; conflicting bindings would misroute host service traffic (e.g. secret socket access). An empty stored value is back-filled instead of erroring.
Source
Thrown at engine/server/session.go:1329
return nil, nil, fmt.Errorf("client %q already exists with different secret token", clientID)
}
// for nested clients running the dagger cli, the session attachable
// connection may not have all of the client metadata yet, so we
// fill in some missing fields here that may be set later by the cli
if client.clientMetadata.AllowedLLMModules == nil {
client.clientMetadata.AllowedLLMModules = opts.AllowedLLMModules
}
if opts.LoadWorkspaceModules {
client.clientMetadata.LoadWorkspaceModules = true
}
if opts.HostServiceProxyClientID != "" {
switch client.hostServiceProxyClientID {
case "":
client.hostServiceProxyClientID = opts.HostServiceProxyClientID
case opts.HostServiceProxyClientID:
default:
return nil, nil, fmt.Errorf("client %q already exists with different host service proxy client %q", clientID, client.hostServiceProxyClientID)
}
}
if opts.SingleQuery {
client.clientMetadata.SingleQuery = true
}
if client.clientMetadata.WorkspaceModuleScope == "" {
client.clientMetadata.WorkspaceModuleScope = opts.WorkspaceModuleScope
}
if opts.SuppressCompatWorkspaceWarning {
client.clientMetadata.SuppressCompatWorkspaceWarning = true
}
if client.clientMetadata.Workspace == nil && !client.workspaceLoaded {
if workspaceRef, ok := workspaceRefFromClientMetadata(opts.ClientMetadata); ok {
ref := workspaceRef
client.clientMetadata.Workspace = &ref
}
}
if client.clientMetadata.WorkspaceEnv == nil && !client.workspaceLoaded {View on GitHub (pinned to 82ba2681db)
Solutions
- Ensure each client ID consistently maps to one host-service proxy client
- Use a distinct client ID for connections that use a different proxy
- Check nested client metadata propagation so the original proxy client ID is preserved
Example fix
// before reconnect(existingClientID, newProxyClientID) // after reconnect(newClientID, newProxyClientID)
Defensive patterns
Strategy: validation
Validate before calling
// ensure proxy client ID is derived from the same client identity
if existingProxyID != "" && newProxyID != existingProxyID {
clientID = newClientID() // use a fresh client ID for a different proxy
} Try / catch
if strings.Contains(err.Error(), "different host service proxy client") {
clientID = newClientID(); reconnect(clientID, proxyID)
} Prevention
- Keep a 1:1 mapping between client ID and proxy client ID
- Preserve the original proxy client ID through nested execs
- Don't reuse a parent's client ID from a differently-proxied subprocess
When it happens
Trigger: Calling getOrInitClient for an existing client where opts.HostServiceProxyClientID is non-empty and != client.hostServiceProxyClientID (stored value also non-empty).
Common situations: A nested exec reuses a parent's client ID but carries its own proxy client ID; misconfigured proxy wiring in module function calls; replayed requests through a different proxy.
Related errors
- proxy conn pool failed: %w
- failed to get engine client: %w
- only the main client can call this function
- client path is required
- SDK name is required
AI-assisted analysis of dagger/dagger@82ba2681db (2026-09-05).
Data as JSON: /api/errors/57422af8da4c18b9.
Report an issue: GitHub.