Zed Wrote Your Secrets Into Its Log File in Plain Text — Fixed in 1.18.1 on Sep 4, and One Command Tells You If You Were Hit

If you use the Zed editor and connect it to a dev container, there may be a file on your machine right now holding your API keys and database passwords — in plain text, no masking.

It was reported on September 1 and fixed on September 4 in Zed 1.18.1. Here is what happened and what to do about it.

The problem in one sentence

When Zed connects to a dev container it runs a long docker exec command. That command carries every environment variable you configured, in the form -e GH_TOKEN=your-real-token.

The bug: Zed wrote that entire command into its own log file, Zed.log — once at DEBUG level, and again at ERROR level in the message it logs when a reconnect fails.

The reporter’s point in the official issue is the important part: Zed.log is not treated as sensitive by users, it is world-readable by default, and it is exactly the file people paste into bug reports.

So the exposure has two layers:

1. Secrets sit in clear text on your disk (shared machines, backups and sync folders carry them along).
2. The moment you helpfully attach that log to a bug report, you have published your key.

Who was affected

The reported environment was Zed 1.17.2 on Linux, with a docker compose based dev container passing secrets through containerEnv or compose environment. The fix landed on stable on 2026-09-04 as 1.18.1, whose release notes list “Fixed dev container environment variables being logged in full.”

Check your own machine with one command

On Linux, Zed’s log lives at ~/.local/share/zed/logs/Zed.log. Search it for the variable names you actually use:

grep -n -E "GH_TOKEN|API_KEY|SECRET|PASSWORD|TOKEN" ~/.local/share/zed/logs/Zed.log

• No output: nothing recorded on this machine right now (rotated older logs usually sit in the same folder).
• Output showing full values: you were hit. Do the three things below.

The official fix works by replacing the value of every -e NAME=VALUE argument with <redacted> before the command is written out.

Three things to do, in this order

First: revoke and reissue the keys. Do not start by deleting the log. Once a secret has sat in plain text on disk — let alone been pasted online — deleting the file does not make it safe again. Regenerate GitHub tokens, cloud keys and database passwords, and invalidate the old ones.

Second: upgrade Zed to 1.18.1 or later. Without the upgrade, the next dev container connection writes the values out again.

Third: clear the old logs. Once the new keys are live, delete the old files under ~/.local/share/zed/logs/, and check whether that folder is being synced to cloud storage or backed up.

One habit worth keeping: before pasting any log online, grep it for secrets yourself. In this very case, the person filing the report redacted the token by hand before posting.

The general lesson: logs are the forgotten leak path

Secrets do not only escape through commits. Log files, error messages, crash reports and the “context” an AI tool ships off are the same class of risk: you think it is debug output, but it is a full snapshot of your environment.

If you use tools like GitHub Copilot that read your project files, the same logic applies to deciding which files an AI should never see — see our Copilot content exclusion setup guide.

FAQ

I am on macOS or Windows — am I affected?

The bug is in the code that builds the docker exec command and writes it to the log, which is not OS-specific; only the log path differs. The reported environment was Linux and the project did not enumerate other systems, so we do not extrapolate. Safest path is the same: upgrade to 1.18.1, then grep your log.

I never shared my log with anyone. Am I fine?

Lower risk, but not zero. A plain-text secret on disk is still exposed if the machine is shared, backed up to the cloud, or read by other software. Reissuing a key usually costs a few minutes — do it.

Why would an editor log the whole command anyway?

Because it is genuinely useful for debugging container connection failures. The fix is not to stop logging but to log with values masked: the command structure stays, the sensitive values become <redacted>.

Sources: Zed issue #63569, “Dev container docker exec command is logged in full, leaking environment secrets into Zed.log” (opened 2026-09-01, closed); fix PR #63735 (cherry-pick to stable, merged 2026-09-04) and #63606; Zed stable release notes at zed.dev/releases/stable (1.18.1, 2026-09-04). All read directly on 2026-09-05. Evidence level: first-party (project repository and official release notes). The project did not enumerate every affected version, so this article names only the reported 1.17.2 and the fixed 1.18.1. More: Zed tool page, Copilot content exclusion guide