# How no-mistakes Acts as a Git Proxy: Local Environment Forwarding Explained

> Learn how no-mistakes acts as a Git proxy by injecting HTTP proxy variables into Git subprocesses for seamless network traversal without manual setup.

- Repository: [Kun Chen/no-mistakes](https://github.com/kunchenguid/no-mistakes)
- Tags: deep-dive
- Published: 2026-07-14

---

**no-mistakes implements a git proxy by baking HTTP proxy environment variables into the daemon's service definition at installation time, then injecting those variables into every Git subprocess to enable transparent network traversal without manual configuration.**

The `no-mistakes` open-source tool inserts a lightweight **git proxy** between your local repository and the remote. Unlike traditional network proxies, this implementation in `kunchenguid/no-mistakes` does not open listening sockets; instead, it ensures that proxy variables like `HTTP_PROXY` and `HTTPS_PROXY` are automatically forwarded to every Git command spawned by the daemon, as documented in [`docs/src/content/docs/start-here/introduction.md`](https://github.com/kunchenguid/no-mistakes/blob/main/docs/src/content/docs/start-here/introduction.md) at line 6.

## What Is the no-mistakes Git Proxy?

The **git proxy** in no-mistakes is not a separate network service but a thin wrapper that intercepts environment variables. When the daemon spawns Git commands—whether for `push`, `fetch`, or `pull` operations—it ensures that the child process inherits the correct `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`, and `ALL_PROXY` values. This design allows Git and its underlying HTTP transports (such as `curl`) to route traffic through corporate or personal proxies without requiring users to export these variables in every shell session.

## How the Git Proxy Works: Three Stages

The proxy logic operates through three distinct phases, implemented primarily in [`internal/daemon/service_render.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/service_render.go) and related files.

### Stage 1: Baking Proxy Variables at Installation

When you run `no-mistakes daemon install` (or `no-mistakes init`, which triggers installation), the installer captures your current shell's proxy environment. In [`internal/daemon/service_render.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/service_render.go) at lines 110-117, the `serviceRenderProxy` function reads both upper- and lower-case variants of proxy variables and bakes them into the generated service definition.

- On Linux, this creates a systemd unit file.
- On macOS, this generates a launchd plist.
- On Windows, this configures a Task Scheduler entry.

The proxy values are stored with their exact casing preserved, ensuring compatibility with tools that expect specific variable names.

### Stage 2: Runtime Environment Resolution

At daemon startup, the process resolves its environment from the login shell (on macOS/Linux) and supplements it with the baked-in proxy entries. This resolution occurs via `serviceRenderProxy` in [`internal/daemon/service_render.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/service_render.go) (lines 113-119) and is utilized by the daemon's command runner in [`internal/daemon/service.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/service.go).

The function `shellenv.ConfigureShellCommand` injects these variables into the child process's environment. This guarantees that every Git subprocess inherits the proxy settings without requiring the user's shell to export them repeatedly.

### Stage 3: Transparent Git Execution

During actual Git operations, the daemon's wrapper in [`internal/git/run.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/git/run.go) forwards the prepared environment directly to the `git` binary. Because the proxy variables are already present in the process environment, Git automatically routes HTTP and HTTPS traffic through the configured proxy. No additional configuration files or Git-specific settings are required from the user after the initial installation.

## Security Considerations and Permission Handling

When proxy URLs contain credentials (username and password), security becomes critical. The no-mistakes proxy implementation handles this in [`internal/daemon/service_systemd.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/service_systemd.go) by writing service files with `0600` permissions, ensuring that only the owner can read potentially sensitive proxy configurations. This behavior is documented in [`docs/src/content/docs/reference/environment.md`](https://github.com/kunchenguid/no-mistakes/blob/main/docs/src/content/docs/reference/environment.md) at lines 68-201, which details the permission handling and persistence across daemon restarts.

## Configuring the Git Proxy

The following examples demonstrate how to configure and use the proxy functionality:

```bash

# 1. Install the daemon – proxy variables present in your shell are baked in

export HTTP_PROXY="http://proxy.mycorp.com:8080"
export HTTPS_PROXY="http://proxy.mycorp.com:8443"
no-mistakes daemon install   # writes a systemd unit with the proxy env

# 2. Run a regular git push – the daemon intercepts the push and uses the baked proxy

no-mistakes push              # daemon spawns: git push origin HEAD

# 3. Change the proxy later – re-install or restart the daemon

export HTTP_PROXY="http://newproxy:8080"
no-mistakes daemon restart    # reads the new env and updates the service file

```

All commands are standard `no-mistakes` CLI invocations; no extra flags are required to enable proxy forwarding.

## Summary

- **no-mistakes** acts as a local git proxy by forwarding HTTP proxy environment variables to Git subprocesses.
- Proxy variables are **baked into the service definition** at installation time via [`internal/daemon/service_render.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/service_render.go).
- The daemon uses `shellenv.ConfigureShellCommand` to ensure every Git operation inherits the correct proxy settings.
- Service files are written with **`0600` permissions** when credentials are present to protect sensitive data.
- The proxy works uniformly across Linux, macOS, and Windows without opening network sockets.

## Frequently Asked Questions

### Does no-mistakes open a network port to act as a proxy?

No. The no-mistakes git proxy does not open a listening socket or intercept network traffic. It is a local environment wrapper that ensures `HTTP_PROXY`, `HTTPS_PROXY`, and related variables are present in the environment of every Git process the daemon spawns. This avoids extra network hops and keeps the implementation simple.

### How do I update proxy settings after installation?

To update proxy settings, export the new environment variables in your shell and run `no-mistakes daemon restart` or `no-mistakes daemon install`. This triggers the `serviceRenderProxy` logic in [`internal/daemon/service_render.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/service_render.go) to read the current environment and regenerate the service definition with the updated values.

### Why does the service file use 0600 permissions?

The service file is written with `0600` permissions (owner read/write only) when the proxy URL contains credentials, as implemented in [`internal/daemon/service_systemd.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/service_systemd.go). This prevents other users on the system from reading sensitive authentication information embedded in the proxy configuration.

### Does this proxy implementation work on Windows and macOS?

Yes. The proxy logic is platform-agnostic. On macOS, it generates a launchd plist; on Windows, it creates a Task Scheduler entry; and on Linux, it writes a systemd unit. All platforms use the same `serviceRenderProxy` function in [`internal/daemon/service_render.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/service_render.go) to embed proxy variables, ensuring consistent behavior across operating systems.