`$env.config.history.path` setting is completely ignored – history always writes to `$nu.history-path`

[ErrorPower2001]

Bug report form

• I have done a basic search of the issue tracker to find any existing issues that are similar.
• I have checked that my version is at least the latest stable release available via my installation method.

Describe the bug

The $env.config.history.path configuration option is completely ignored. Regardless of what custom path is set, Nushell always writes history to the $nu.history-path — both during the session (when sync_on_enter = true) and on exit (when sync_on_enter = false).

How to reproduce

In REPL prompt:

1. Set a custom history path:

# Linux
> $env.config.history.path = "/dev/null"
## or "/home/username/tmp/nushell/"
## or "/home/username/tmphistory.txt"

# or Windows
> $env.config.history.path = "\\\\.\\NUL"
## or '\\.\NUL'
## or "C:\\Users\\username\\tmp\\nushell\\"
## or "C:\\Users\\username\\tmphistory.txt"

2. Run commands:

> print "test"
> # test in common

3. The history still write to $nu.history-path

> open $nu.history-path
$env.config.history.path = '/home/username/tmphistory.txt'
print "test"
# test in common

> open $env.config.history.path
Error: nu::shell::io::file_not_found

  × File not found
   ╭─[repl_entry #8:1:6]
 1 │ open $env.config.history.path
   ·      ────────────┬───────────
   ·                  ╰── File not found
   ╰────
  help: '/home/username/tmphistory.txt' does not exist

> print $nu.history-path ; print $env.config.history.path
/home/username/.config/nushell/history.txt
/home/username/tmphistory.txt

Expected behavior

When $env.config.history.path is set to a custom path, Nushell should respect that setting and write history to the specified path. If the path is /dev/null/ on Linux or \\.\NUL on Windows (UNC path), no file should be created on disk.

Configuration

Linux

key	value
version	0.112.2
major	0
minor	112
patch	2
branch	makepkg
commit_hash	d80ee8c
build_os	linux-x86_64
build_target	x86_64-unknown-linux-gnu
rust_version	rustc 1.94.1 (e408947bf 2026-03-25) (Arch Linux rust 1:1.94.1-1)
cargo_version	cargo 1.94.1 (29ea6fb6a 2026-03-24) (Arch Linux rust 1:1.94.1-1)
build_time	2026-04-16 08:49:55 +00:00
build_rust_channel	release
allocator	standard
features	default, mcp, network, plugin, rustls-tls, sqlite, trash-support
installed_plugins
experimental_options	example=false, reorder-cell-paths=true, pipefail=true, enforce-runtime-annotations=false, native-clip=false, cell-path-types=false

Windows

key	value
version	0.112.2
major	0
minor	112
patch	2
branch
commit_hash	d80ee8c
build_os	windows-x86_64
build_target	x86_64-pc-windows-msvc
rust_version	rustc 1.92.0 (ded5c06cf 2025-12-08)
rust_channel	1.92.0-x86_64-pc-windows-msvc
cargo_version	cargo 1.92.0 (344c4567c 2025-10-21)
build_time	2026-04-15 21:31:35 +00:00
build_rust_channel	release
allocator	standard
features	default, mcp, network, plugin, rustls-tls, sqlite, trash-support
installed_plugins
experimental_options	example=false, reorder-cell-paths=true, pipefail=true, enforce-runtime-annotations=false, native-clip=false, cell-path-types=false

[ErrorPower2001]

The feature $env.config.history.path was requested in #17419 and implemented in #17425

[fdncred]

@kx0101 would you mind looking into this? I have not validated the claim myself. Maybe @NotTheDr01ds could help too?

[kx0101]

@fdncred glad to take a look at it! thanks for tagging me

[kx0101]

had a looked into this. The custom path actually does work, but only when set in config.nu (or via --config/env)

I tested both:

• In config.nu: history goes to the custom path, default history.txt isn't created, and $nu.history-path shows the custom value
• At the REPL prompt (like in your repro): the config value updates, but reedline keeps writing to the original path, and $nu.history-path still shows the default

the reason is that setup_history runs once at REPL startup and hands the history file to reedline. After that, changing $env.config.history.path doesn't rebuild reedline's history backend.

$nu.history-path is also a startup-time constant.

@ErrorPower2001 where are you setting $env.config.history.path, in config.nu, or at the prompt? If it's in config.nu and still not working for you, can you share the relevant snippet so I can repro?

@fdncred do you think runtime changes should also be supported? If yes I can look into it. If not, I should probably mention it in the docs

[ErrorPower2001]

@ErrorPower2001 where are you setting $env.config.history.path, in config.nu, or at the prompt? If it's in config.nu and still not working for you, can you share the relevant snippet so I can repro?

Thanks for the investigation. I was setting it at the REPL prompt, not in config.nu.

My goal is to stop the current session from writing subsequent commands to the history file — essentially disabling history persistence on-the-fly mid-session for privacy, without restarting the shell.

If runtime changes aren't planned, a note in the docs would help. But supporting this would be great for ad-hoc privacy needs.

[kx0101]

Ah, I see! Cool, let's wait for @fdncred's answer and see what we can do

I'm happy to do either 😄

[fdncred]

That's what I suspected too. I've asked the core-team if anyone thinks it's necessary/helpful to dynamically change the history path. I don't see the need to do this, others may feel differently.

If we don't want it dynamically changable, we should probably disallow $env.config.history.path changing from the repl and give an error. We do something like that for $nu right now.

So, let's wait to see if anyone else chimes in. Thanks for the research @kx0101! ❤️

[kx0101]

@fdncred of course! anytime! and great idea btw, I like giving back an error to the user when they attempt to change it 😄

I'll open a PR for this

[stormasm]

I've asked the core-team if anyone thinks it's necessary/helpful to dynamically change the history path.

I don't see the need to do this either...

Because...

An example of lets keep our software simple...

Why add complexity where it is not needed....

[ErrorPower2001]

Should we standardize the behavior of history option changes? sync_on_enter and ignore_space_prefixed can take effect during REPL changes (I'm not sure about isolation), while other history options require modification during the startup phase and cannot be modified or take effect in the REPL.

Should we add annotations to all $env.config entries, indicating which should be modified during the startup phase and which can be modified during the REPL phase? Or should we move all options that can be modified during the REPL phase into a new $env.config_repl category?

[fdncred]

It would be nice to make all that can't be changed in the repl immutable there. I'm not sure which those are exactly. I'm against adding $env.config_repl.