McpStdioServer missing `env` field — proto supports it but Python model doesn't expose it

[jiridanek]

Environment

• google-antigravity SDK v0.1.3
• Python 3.14
• macOS

Description

McpStdioServer has no env field, but the underlying proto (McpStdioTransport) has an env map field (field number 3). The converter function _to_mcp_server_proto() also doesn't pass env vars through.

This means there's no way to set environment variables for MCP stdio servers launched by the agent — for example, passing API keys or configuration that the MCP server process needs.

Evidence

The proto defines env support:

>>> import google.antigravity.connections.local.localharness_pb2 as pb
>>> [f.name for f in pb.McpStdioTransport.DESCRIPTOR.fields]
['command', 'args', 'env']
>>> t = pb.McpStdioTransport()
>>> type(t.env)
<class 'google._upb._message.ScalarMapContainer'>

But the Python model doesn't expose it:

>>> from google.antigravity.types import McpStdioServer
>>> list(McpStdioServer.model_fields.keys())
['name', 'timeout_seconds', 'command', 'type', 'args', 'enabled_tools', 'disabled_tools']

And _to_mcp_server_proto() doesn't pass it:

# local_connection.py, _to_mcp_server_proto()
if isinstance(server_cfg, types.McpStdioServer):
    kwargs["stdio"] = localharness_pb2.McpStdioTransport(
        command=server_cfg.command,
        args=server_cfg.args,
        # env= not passed
    )

Proposed Fix

1. Add env: dict[str, str] | None = None field to McpStdioServer in types.py
2. Pass env=server_cfg.env or {} in _to_mcp_server_proto()

This aligns with the MCP spec's stdio transport, which defines env as an optional environment variables map.

Workarounds

1. Process-level env: Set the env vars on the parent process before creating the agent, so the Go harness inherits them. This pollutes the parent process environment and doesn't allow per-server env isolation.

2. /usr/bin/env wrapper: Rewrite the MCP server definition to use command="/usr/bin/env" with args=["KEY=value", "actual-command", ...]. This works but leaks secrets into ps -ef output and is fragile.

Neither workaround is suitable for production use with secrets.

[NTaylorMullen]

on it