Sometimes. Bash skips lines that start with a space only when HISTCONTROL includes ignorespace, and zsh needs the HIST_IGNORE_SPACE option. Neither is a security control. It is a convenience that fails silently when the setting is off, so the safer habit is to never type a secret into a command at all.
What the shell manuals say
The bash manual describes HISTCONTROL as a colon-separated list of values that control how commands are saved. If the list includes ignorespace, lines that begin with a space character are not saved in the history list. The value ignoredups drops lines that match the previous entry, and ignoreboth is shorthand for both.
Zsh has a similar option. HIST_IGNORE_SPACE removes command lines from the history list when the first character is a space. The zsh manual adds a detail worth knowing: the command lingers in the internal history until the next command is entered, so you can briefly reuse it with the up arrow.
The key point is that both behaviours are opt-in. On a fresh machine, a container, a colleague's laptop or a remote server you SSH into, the setting may be missing, and a space-prefixed command is saved like any other.
Why this is a weak control
Three problems come up in practice.
First, it depends on memory. You have to remember the space every time, and you only find out you forgot when the secret is already on disk.
Second, it only covers the history file. A secret typed on a command line can still show up in other places, such as terminal scrollback, a screen share or a recording, or a shell prompt that you paste into a ticket.
Third, it hides the evidence from you as well. If you need to reproduce a command for a teammate, a hidden history entry is gone.
Safer habits that do not rely on a space
Move the secret out of the command. A few patterns work in most shells:
- Read it from a file with tight permissions, or from your password manager's command line tool, at the moment the command runs.
- Use a tool's own credential store. Many CLIs have a login command that saves a token in the operating system keychain, so you never type it again.
- Pipe it through standard input instead of passing it as an argument, when the tool supports that.
- Prefer short-lived credentials from a sign-in flow, so a token that does land in history expires soon.
If you spot a secret in history, treat it as exposed: rotate it, then clean the file. Deleting the history line alone does not undo the exposure, since backups, synced home directories and other tools may have copied it.
A quick audit you can run today
Check whether your shell has the setting on, then decide whether you want it as a safety net. In bash, print the variable with echo "$HISTCONTROL". In zsh, run setopt | grep -i histignorespace. Then search your history for obvious strings such as token=, password= or Authorization: to see whether any real values have ended up there. If you find any, rotate them before you do anything else.
Where Safeguard fits
Safeguard works on the dependency and code side of your software: SBOM and dependency scanning, reachability analysis and policy gates. It does not store or manage credentials, so keep using your password manager, secrets manager or cloud identity for that. You can run a free scan of a project at gold.safeguard.sh/scan.
Quick check
Is ignorespace enabled by default in bash?
The bash manual says that if HISTCONTROL is unset or has no valid value, bash saves all lines. Check your own shell, because distribution defaults and dotfiles differ.
Does clearing history remove the exposure?
No. It removes one copy. If the secret was live in a shell, treat it as exposed and rotate it.
What is the better fix?
Do not pass secrets as typed arguments. Use a credential store, standard input or a short-lived sign-in.
Sources
Last reviewed: 19 October 2026.
