Recently (possibly with the Sonoma update, but possibly even more recently than 14.0), Apple Terminal has been giving the following error on startup (when macOS is set to restore windows, i.e., when System Settings > Close windows when quitting… is unset):

date: illegal time format
usage: date [-jnRu] [-I[date|hours|minutes|seconds]] [-f input_fmt]
            [-r filename|seconds] [-v[+|-]val[y|m|w|d|H|M|S]]
            [[[[mm]dd]HH]MM[[cc]yy][.SS] | new_date] [+output_fmt]
-bash: Saving: command not found

I have traced this to an error coming from /etc/bashrc_Apple_Terminal which is largely concerned with saving and restoring sessions for the various terminal tabs and windows.

It comes from the lines

    if [ -r "$SHELL_SESSION_FILE" ]; then

On shell startup, this snippet runs, and then deletes, "$SHELL_SESSION_FILE", which is written at shell exit by the following lines:

    if [ -n "$SHELL_SESSION_FILE" ]; then
        echo -ne '\nSaving session...' >&2
        (umask 077; echo 'echo Restored session: "$(/bin/date -r '$(/bin/date +%s)')"' >| "$SHELL_SESSION_FILE")
        declare -F shell_session_save_user_state >/dev/null && shell_session_save_user_state
        shell_session_history_allowed && shell_session_save_history
        echo 'completed.' >&2

The error occurs because $SHELL_SESSION_FILE incorrectly contains the following text:

Saving session...echo Restored session: "$(/bin/date -r 1698759014 Saving session...)"

rather than echo Restored session: "$(/bin/date -r 1698759014) For some reason, the Saving session... text is appearing in the file (twice!).

I think I didn't make any changes to cause this, but perhaps I am wrong. The directory ~/bash_sessions/ seems to have recent files with this error, and slightly older files (as recent as yesterday!) which don't. I regularly update various packages with homebrew, and I have recently installed Python 3.12 from python.org, but I can't see how they could reach into the guts of shell startup.

Update: In fact, I see this even with a new user, and even if I use zsh rather than bash! (Apple Terminal has very similar code for session history management under zsh.) So it seems that some other recent change to my system is causing this. But I suspect it's not simply a Sonoma problem, since it does not appear to be widespread. Yikes!

Update 1a: Note that the code is run via trap shell_session_update EXIT. The error only seems to happen when I exit the shell by quitting Terminal.app, but not when I just use the exit command. (And I've even tried explicitly sending various signals to the shell via kill -n, but I can't seem to induce the error that way.)

Update 2: At least one other person is seeing this! Perhaps this indicates an issue with VS Code?

Update 3: After some back and forth in the comments below, it is clear that the error spans multiple versions of macOS on both Intel and Apple Silicon architectures, and we seem to have eliminated VS Code and possibly Python (we seem to be using different versions and installers) as the cause; I have removed /opt/homebrew and rebooted and still seeing the issue. Is it possible that any of these things somehow "pollutes" the environment -- e.g., /etc/ -- in some way that remains in place?

Is anyone else seeing this? Any ideas what's happening (or even debugging suggestions)?

I've asked a more specific version of this question over on Unix & Linux SA.

  • 1
    If you make a new user on the Mac, does it too emit that error? My hunch is your user profile has some startup file and not that the system is broken and this is a quick test to triage and narrow down where to look.
    – bmike
    Oct 31 at 14:00
  • 1
    I would worry about /usr/local/bin, there may be commands there which shadow the Apple ones and have different options.
    – nohillside
    Nov 3 at 14:37
  • 1
    I've got exactly the same problem with iMac, macOS version 12.7.1. And my MacBook with macOS 14.1 works fine (very similar setup otherwise). Nov 11 at 18:42
  • 1
    @AndrewJaffe iMac had VS Code 1.84.1, Macbook had VS Code 1.84.0. Upgraded Macbook to VS Code 1.84.2, rebooted, and now I'm also seeing the familiar error message there. Nov 12 at 20:41
  • 1
    I don’t have VSCode installed.
    – nohillside
    Nov 12 at 21:36

3 Answers 3


Since I've been asked to do so in .zsh_sessions producing an error I post here the fact that commenting out the echo line did make the problem disappear in a similar case:

I commented out the echo -ne line in etc/zshrc_Apple_Terminal and the problem disappeared

  shell_session_save() {
    # Save the current state.
    if [ -n "$SHELL_SESSION_FILE" ]; then
        # echo -ne '\nSaving session...' >&2
        (umask 077; echo 'echo Restored session: "$(/bin/date -r '$(/bin/date +%s)')"' >| "$SHELL_SESSION_FILE")

As per a user suggestion, so does replacing it by

print -u 2 $'\nSaving session ...' 
  • 1
    This solves the symptom, but it doesn't really give any insight into why the problem is occurring (which we still don't know!). And even with something like this solution (which I have also tried) I actually still get similar errors tracing back to the printf statement elsewhere in bashrc_Apple_Terminal. Nov 8 at 14:43
  • 2
    @AndrewJaffe Any answer helping users to avoid the problem til Apple fixes it is welcome.
    – nohillside
    Nov 8 at 14:51
  • 1
    @nohillside, Agreed, although what still isn't clear is whether this is (only) an Apple problem -- in which case maybe we can expect a fix from them -- or is it that those of us who are seeing it all have (e.g.) some common 3d-party software -- in which case we might be on our own! (I have actually filed a bug using Feedback Assistant) Nov 8 at 15:02
  • 1
    @AndrewJaffe The shell functions run for a specific user, so cross-user dependencies are unlikely. And if you only start one shell for a user, timing issues (which locking would solve) seem unlikely as well. Not sure we clarified the /usr/local/bin thing, is there anything in there which is also called from the session functions?
    – nohillside
    Nov 8 at 18:24
  • 1
    @Hugues, that directory (…Frameworks…/bin) is added to your path when you install Python from python.org, which explicitly changes your bash startup files — look in /Applications/Python\ 3.12 — whereas /usr/local/bin is probably homebrew Python. (Did you edit your startup files yourself in your attempts to fix this and ended up changing your path?) What’s interesting to me is that I recently switched from homebrew Python to the one downloaded from Python.org, and that is around when I started seeing these issues. So perhaps it is related? Nov 9 at 7:26

Since you have determined that your startup files are causing this (by testing a new user account without any customizations), I would take these next approaches.

  1. Run your modified files through a linter. Shell check is excellent in my experience: https://www.shellcheck.net/
  2. Set debug flag for bash early in your script.
  3. Closely look at any use of the variable you identified as getting stomped.

For item 2, perhaps you can set an alternate shell temporarily and then call bash:

/bin/bash -lixc exit 2>&1 | less

if your <GUID.session> file is unclean - we'll need to pick apart why your customizations are breaking that file generation in the function shell_session_save - on my system this is as follows:

me@mac ~ % which shell_session_save
shell_session_save () {
    if [ -n "$SHELL_SESSION_FILE" ]
        echo -ne '\nSaving session...' >&2
            umask 077
            echo 'echo Restored session: "$(/bin/date -r '$(/bin/date +%s)')"' >| "$SHELL_SESSION_FILE"
        whence shell_session_save_user_state > /dev/null && shell_session_save_user_state "$SHELL_SESSION_FILE"
        local f
        for f in $shell_session_save_user_state_functions
            $f "$SHELL_SESSION_FILE"
        shell_session_history_allowed && shell_session_save_history
        echo 'completed.' >&2

What’s curious is zsh is also reported to have a curiously similar issue.

  • Well, I know exactly where the error occurs: it's in the line echo -ne '\nSaving session...' >&2, incorrectly writing to a file instead of stderr (although I think there are some rare occasions where other incorrect characters are being written to $SHELL_SESSION_FILE). And although the error seems to require (my?) startup files, I'm not completely sure that it's the files themselves that are causing the problems. Nov 1 at 22:46
  • Quite the mystery - I'm glad you know exactly where it occurs - it's hard for me to guess from here @AndrewJaffe but perhaps my thinking will help you over the gap between now and a fix.
    – bmike
    Nov 1 at 22:52
  • 1
    correct - I should have changed my shell to get that / got carried away with calling bash from zsh... @AndrewJaffe
    – bmike
    Nov 1 at 23:18
  • 1
    Got a similar issue, likely from the same shell_session_save line when using zsh. apple.stackexchange.com/questions/466160/…
    – Hugues
    Nov 8 at 0:20
  • 1
    Yes, I'm still on 12.7.1, as I did not want to upgrade for various reasons. It could however still be a MacOs X issue as there are regular updates for security reasons and there was one in October.
    – Hugues
    Nov 9 at 14:44

I saw this today! Haven't seen it before. I'm on Monterey (12.7.1 21G920).

I rebooted my MacBook today (not installing the update, just a normal reboot). After it restarted, I noticed that it didn't properly restore all my Terminal tabs, but instead restored the state from around Nov 2.

I think I quit the Terminal later again, and after I opened it again, I now saw this in every restored tab:

/Users/kuba/.zsh_sessions/C6E94843-05DC-43CC-933E-5190FC8E0825.session:2: command not found: Saving

I haven't seen that message before. I have a suspicion that it might have something to do with why the Terminal restored tabs state from Nov 2 instead of from before reboot… perhaps they've changed the way how sessions are stored in some recent update? (updated zsh to some new version?)

(More info: I don't have VS Code installed, I have Homebrew installed, but not many packages in it, and also MacPorts.)

New contributor
Kuba Suder is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • thanks. Did you install anything or make any changes to your system since the previous reboot? Nov 27 at 10:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .