---
title: "The tilde in your PATH may not be your HOME"
slug: the-tilde-in-your-path-may-not-be-your-home
url: https://listedarticles.com/articles/the-tilde-in-your-path-may-not-be-your-home
canonical_url: https://disconnect3d.pl/2026/10/02/dont-put-tilde-in-your-path/
content_type: tutorial
language: en
published_at: 2026-10-02T00:00:00.000Z
updated_at: 2026-10-11T14:10:07.721Z
author: "disconnect3d"
authored_by: human
publisher: "disconnect3d.pl"
publisher_url: https://disconnect3d.pl/
topics: ["Security", "Programming"]
license: all-rights-reserved
word_count: 373
reading_minutes: 2
citation: "disconnect3d, disconnect3d.pl. \"The tilde in your PATH may not be your HOME.\" 2 Oct 2026. https://disconnect3d.pl/2026/10/02/dont-put-tilde-in-your-path/ (all-rights-reserved)"
# The full text follows. The web page shows an extract and sends readers
# to the source above; quote the citation and link the canonical URL.
---

# The tilde in your PATH may not be your HOME

> A short warning that writing export PATH="$PATH:~/.local/bin/" in a shell rc file leaves a literal tilde in PATH because tilde expansion only happens in unquoted words, which can let sandboxed tools write to unexpected directories; it shows how to check for and fix it with $HOME.

I was playing with the [nono](https://nono.sh/) agent sandboxing tool and it greeted me with a warning: `PATH entries the sandbox can write to: ~/.local/bin/` which looked suspicious.

![nono warning about PATH entries the sandbox can write to](https://disconnect3d.pl/assets/posts/tilde-in-path-nono-warning.png)

In other words, doing this in your `~/.bashrc` or `~/.zshrc`:

```
export PATH="$PATH:~/.local/bin/"
```

will not expand the `~` (tilde) into the home path (or `$HOME`) as the tilde to home expansion happens only in unquoted inputs, as also the [bash documentation says](https://www.gnu.org/software/bash/manual/html_node/Tilde-Expansion.html):

> If a word begins with an unquoted tilde character (‘~’), all of the characters up to the first unquoted slash (…) are considered a tilde-prefix. (…)
>
> Bash checks each variable assignment for unquoted tilde-prefixes immediately following a ‘:’ or the first ‘=’, and performs tilde expansion in these cases. (…)

So instead of having `/home/<user>/.local/bin/` added to `PATH` we end up with `./~/.local/bin/` added to `PATH`.

And to fix this, we can do this:

```
export PATH="$PATH:$HOME/.local/bin/"
```

Note that the unquoted version `export PATH=$PATH:~/.local/bin` actually works in Bash and Zsh, because tilde expansion is also performed in variable assignments after `=` and after each `:`. But relying on that is fragile as for example, a whitespace will break the variable assignment.

The problem can also be seen here:

```
$ ls -la
total 0
drwxr-xr-x@   2 dc  staff    64 Oct  2 13:37 .
drwxr-x---+ 105 dc  staff  3360 Oct  2 13:37 ..
$ mkdir -p ./~/.local/bin/
$ printf '#include <stdio.h>\nint main() { puts("hello"); }'>a.c; gcc a.c -o ./~/.local/bin/kek
$ PATH="~/.local/bin/" kek
hello
$ tree -f
.
├── ./~
│   └── ./~/.local
│       └── ./~/.local/bin
│           └── ./~/.local/bin/kek
└── ./a.c

4 directories, 2 files
```

![Demo showing that a literal tilde in PATH resolves to a ./~/ directory in the current working directory](https://disconnect3d.pl/assets/posts/tilde-in-path.png)

As we can see, the `kek` binary was found and executed from `./~/.local/bin/` — the home directory was never involved.

## Check your PATH

You can quickly check whether you have this problem with:

```
$ echo "$PATH" | grep -- '~'
```

or, to see each entry on its own line:

```
$ echo "$PATH" | tr ':' '\n' | grep '~'
~/.local/bin/
```

If it prints anything, go fix your `.bashrc`/`.zshrc`/`.profile` and replace the `~` with `$HOME` :).

Btw, kudos to the nono tool for warning about this - even though the warning could be more verbose (PR incoming).