Git.Zone IDE: AI Agents on Remote Workspaces Without Sending Keys Remote

Git.Zone IDE keeps SSH and AI credentials local while giving SmartAgent native access to the remote workspace where files, terminals, Git, builds, and tests actually run.

Git.Zone IDE is an AI-first remote IDE built around a sharp boundary: SmartAgent can operate inside the remote workspace, while SSH keys and AI authentication remain on the local machine.

Theia over SSH is part of the implementation, but it is not the central product idea. The remote Theia backend gives the agent and the user a workspace substrate. The local Electron shell keeps the trust boundary, the SSH policy surface, the model connection, and the permission prompts.

The git.zone/ide repository is public and contains open-source code licensed under MIT. Its root package description is Remote-first Git.Zone IDE based on Theia, Electron, and SSH. The repository is public, while the workspace packages are currently private/unpublished package workspaces. The more precise operational framing is AI-first remote development: files, terminals, Git, language servers, builds, tests, and agent-assisted edits run on the SSH host where the project actually lives.

The May code.foss.global update noted that GitZone remote workspaces were moving from scaffold to product-shaped implementation. This dispatch corrects the emphasis: the interesting split is between local secrets and remote execution.

Ecosystem note. code.foss.global is the project forge and registry behind the monthly engineering updates. Git.Zone IDE is a Git.Zone product built on that stack, with SmartAgent handling agent workflows through explicit local permissions.

The credential split

The local Electron shell handles SSH host selection, runtime staging, local port forwarding, project tabs, and the SmartAgent control surface. SSH transport is delegated to the system ssh binary, so existing OpenSSH configuration remains the contract.

Git.Zone IDE reads standard entries in ~/.ssh/config, including HostName, User, Port, IdentityFile, ProxyJump, and ForwardAgent. That means the same agents, hardware keys, bastion hosts, and enterprise SSH rules used from a terminal are used by the IDE.

AI authentication stays on the local side as well. In the Electron shell, GitZoneAgentRuntime owns SmartAgent sessions and stores them under ~/.git.zone/ide/agent-sessions. Model creation reads OPENAI_API_KEY, OPENAI_TOKEN, local ChatGPT or Codex auth, or SmartAI auth from the local process and local auth stores. Those provider credentials are not exported into the remote command environment.

Surface	Owner	What the remote runtime receives
SSH private keys, SSH agent, hardware-key flow	Local OpenSSH	SSH authentication handled by the user's configured `ssh` path
AI provider tokens and ChatGPT/Codex/SmartAI auth	Local Electron shell and SmartAI side	No copied model credentials in remote tool environments
Project files, Git, builds, tests, terminals	Remote SSH host	Explicit file operations and commands run in the active project
Theia workspace backend	Remote SSH host, loopback only	A browser IDE served through the shell-managed SSH tunnel

There is one important caveat: if a user configures OpenSSH with ForwardAgent yes, normal OpenSSH agent-forwarding semantics apply. Git.Zone IDE does not change that contract. It also does not copy SSH private keys, AI API keys, ChatGPT auth, or SmartAI credentials into the remote Theia runtime.

SmartAgent has remote hands, local policy

SmartAgent runs with a local model connection and remote workspace tools. The system prompt identifies the session as the Git.Zone IDE SmartAgent for a remote SSH workspace and tells the agent to use remote tools instead of assuming that the local filesystem is the project filesystem.

The code path matches that prompt. createRemoteTools() builds SmartAgent shell, filesystem, and browser tools from a tool execution context. The shell tool calls runRemoteShellCommand(context, command, ...), which executes through ideSsh.runSshCommand on the selected host in the remote project working directory.

That detail matters for agent behavior. When SmartAgent runs git status, starts a build, reads a generated file, or executes a test command, it is using the repository, toolchain, environment, and network position of the remote host. The model is local from a credential perspective, but the work happens where the project state exists.

File tools follow the same shape. They call runRemoteNodeTool() over SSH with the staged runtime Node.js binary. The tool environment carries specific path and content data plus GITZONE_AGENT_ROOT. Path traversal checks keep file operations rooted to the active project directory, and the tool environment does not include AI auth credentials.

Permission is local. requestPermission gates tool actions through the Electron UI, and mutating actions plus shell commands require user approval before execution. The remote host receives the specific SSH-executed command or file operation that the user permitted, not the user's model credentials.

Theia is the workspace substrate

Remote Theia still matters. Git.Zone IDE uses Eclipse Theia as the browser IDE backend running on the selected SSH host. The current application uses Theia 1.71.0 packages and includes the editor, filesystem, terminal, SCM, tasks, search, preferences, workspace support, Monaco, markers, messages, process support, plugin extension support, and VSX registry integration.

Each active project starts a Theia backend on the remote host, bound to 127.0.0.1. The Electron shell opens a local SSH tunnel to that loopback port and renders the workspace in a webview. The remote backend is not intended to be reachable as a public IDE service.

Local Electron Shell
  | owns SSH selection, tunnel setup, AI auth, SmartAgent sessions, permissions
  | uses system ssh and local model authentication
  v
Remote SSH Host
  | runs Theia, files, terminals, Git, language servers, builds, tests
  | binds Theia to 127.0.0.1
  v
Shell-managed SSH Tunnel
  | forwards local loopback to remote loopback
  v
Electron WebView + SmartAgent Panel
  | displays the workspace and requests explicit remote tool actions

The Electron security layer also narrows what the shell will load. Git.Zone IDE URLs must resolve to local Theia addresses such as 127.0.0.1, localhost, or loopback equivalents; non-local Git.Zone IDE URLs are refused.

The current Theia app ships with Git.Zone product and remote-environment extensions and uses Dark 2026 as the default theme. Theia is the IDE surface the agent works inside, not the place where AI provider secrets need to live.

Runtime staging and project state

When a host is selected, the shell stages a content-addressed ephemeral runtime into /tmp/gitzone-ide-* on the remote machine. The cache marker .gitzone-runtime-sha256 records the expected hash, so uploads are skipped when the remote runtime already matches.

The runtime payload includes a local Node.js binary bundled with the remote Theia payload. The remote runtime path does not require remote pnpm, which keeps startup focused on SSH reachability, project path validation, and cache state instead of remote package-manager setup.

Project and preference state has explicit locations. The remote project registry lives in ~/.git.zone/ide/projects.json. Theia settings live under ~/.git.zone/ide/theia. Workspace preferences live under .git.zone/ide/workspace, while existing .vscode preferences are still honored.

Security model and caveats

The local app is the trust boundary and the policy surface. It selects the SSH target, launches the tunnel, owns SmartAgent model authentication, stores local agent sessions, and asks for permission before commands or writes are sent to the remote host.

Theia binds to 127.0.0.1 on the remote host.
Access goes through a local SSH tunnel controlled by the Electron shell.
SSH keys remain governed by local OpenSSH configuration.
AI provider credentials remain on the local Electron/SmartAI side.
Agent file tools are rooted to the active project directory.
Shell commands and file writes require user permission.
Runtime uploads are content-addressed and reused when the cached hash matches.

This does not make an untrusted remote machine safe. Commands still run on that machine, project files are read and written there, and the remote environment can affect build and test results. The point is narrower: the remote workspace can be the execution environment without becoming the place where SSH private keys or AI provider tokens are stored.

What changed in May

Recent May work moved the IDE from scaffold toward a working remote-agent product: SSH launcher, cached remote runtime, remote project tabs, local Theia loading, SmartAgent runtime integration, ChatGPT auth, model and reasoning controls, streamed reasoning summaries, SmartAgent tool contexts, attachment support, the Dark 2026 theme, and secure local Theia URL handling.

That work changes the shape of the product. Git.Zone IDE is not only a remote editor launcher. It is an AI-first remote development environment where the agent can use the remote filesystem, terminals, Git, builds, tests, and project-local execution semantics while the local machine retains the credential boundary.

The remote box becomes the place where the code runs. The local app remains the place where keys, model auth, and permission decisions are owned.