{"slug": "managing-claude-code-sessions-through-lynx", "title": "Managing Claude Code Sessions Through Lynx", "summary": "Tigera's Lynx gateway can route Claude Code model traffic by setting the ANTHROPIC_BASE_URL environment variable to the gateway's /llm/anthropic endpoint, giving platform teams visibility into which coding sessions use AI, which model providers and models they call, what data is sent, which policies were applied, and which MCP tools and sub-agents were invoked. Tigera notes the gateway governs only what leaves the machine, not local tool execution such as file reads, source edits, or shell commands, and that a governed laptop is not a sandbox. The company positions the gateway as a complement to isolation work from Anthropic's bubblewrap and seatbelt sandboxing and egress-firewall devcontainer, Docker's coding-agent sandboxes, and Kubernetes-based workload isolation.", "body_md": "At Tigera, we spend a lot of time thinking about agent security: identity, policy, runtime controls, and the record left behind after an agent acts.\n\nCoding agents create an interesting problem because, in most organizations, they didn’t arrive through the front door.\n\nFew companies ran a platform evaluation and rolled Claude Code out to 500 developers. Developers installed it themselves. By the time security and platform teams started asking how coding agents should be governed, they were already running on laptops with access to source code, credentials, SSH keys, kubeconfigs, internal services, and whatever else the developer could reach.\n\nThe long-term answer is increasingly clear I think: move coding agents into isolated environments you control.\n\nAnthropic’s sandboxing work draws filesystem and network boundaries using OS primitives such as bubblewrap and seatbelt. Its reference devcontainer includes an egress firewall. Docker has introduced sandboxes for running coding agents, and Kubernetes-based approaches can add stronger workload isolation, network policy, and disposable development environments.\n\nThat direction makes sense.\n\n*Isolation governs what an agent can do. A gateway governs what it can send.*\n\nAnd unlike a complete move to remote development environments, the second boundary is something you can introduce today.\n\n## Start with one environment variable\n\nClaude Code allows its model endpoint to be configured through the environment.\n\nInstead of connecting directly to Anthropic, point it at the Lynx gateway.\n\n```\nexport ANTHROPIC_BASE_URL=\"https://<lynx-gateway>/llm/anthropic\"\n```\n\nThat’s the entire change on the developer’s machine.\n\n- No endpoint agent. No daemon. No certificate installation.\n- No rebuilt development environment.\n\nThe next model turn goes through Lynx, and every model turn after it does too.\n\nThat small change turns otherwise disconnected model calls into something more useful: a coding session that can be observed, governed, and recorded.\n\n## What this gives you\n\nInstead of seeing another HTTPS connection from a developer laptop to an AI provider, the platform can start answering important questions:\n\n- Which coding sessions are using AI?\n- Which model providers and models are they using?\n- What information is being sent to those models?\n- Which policies were applied?\n- Which MCP tools were called through the gateway?\n- Did the session spawn sub-agents?\n- What happened during a particular coding session?\n\nThat is a significant improvement over an unmanaged agent talking directly to a model provider.\n\n## What this does not do\n\nA gateway gives you a strong answer to what left the building, not what happened on the machine.\n\n- Local tools run on the laptop and do not transit the gateway.\n- Example: Claude Code reads a file, edits source code, or runs a shell command locally.\n- Some of that activity may appear in model traffic (e.g., tool calls, results, retrieved files, or other context).\n- That is observation, not enforcement.\n\n## A governed laptop is not a sandbox\n\nRouting Claude Code through a gateway does not suddenly give Lynx control over the developer’s machine.\n\n- Every model turn that transits the gateway can be governed.\n- MCP calls can also be governed when the MCP server is reached through the gateway.\n- Local tools are different. The gateway isn’t on that execution path and cannot prevent it.\n\nBut that is observation, not enforcement.", "url": "https://wpnews.pro/news/managing-claude-code-sessions-through-lynx", "canonical_source": "https://www.tigera.io/blog/managing-claude-code-sessions-through-lynx/", "published_at": "2026-09-30 15:00:00+00:00", "updated_at": "2026-09-30 16:19:22.049171+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-policy", "developer-tools", "agent-protocols"], "entities": ["Tigera", "Lynx", "Claude Code", "Anthropic", "Docker", "Kubernetes", "bubblewrap", "MCP"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/managing-claude-code-sessions-through-lynx", "markdown": "https://wpnews.pro/news/managing-claude-code-sessions-through-lynx.md", "text": "https://wpnews.pro/news/managing-claude-code-sessions-through-lynx.txt", "jsonld": "https://wpnews.pro/news/managing-claude-code-sessions-through-lynx.jsonld"}}