There is some sensitive data (credit card numbers and such) that I store on my hard drive, encrypted. I use a script to decrypt the data and display it in the terminal window. When I am finished, I would like the script to clear the terminal, so that the sensitive data can no longer be viewed (even if someone gains access to my computer).

I have read here that +k clears the terminal output. To implement this in a script, I used AppleScript as suggested in the accepted answer to this question:

/usr/bin/osascript -e 'tell application "System Events" to tell process "Terminal" to keystroke "k" using command down'

Finally, my script closes the terminal window with

killall Terminal

The problem: if I leave the terminal window with the sensitive output open for about 30 seconds or longer before closing if, then the next time I open terminal, it restores the sensitive data (the text [restored] is displayed below it). If the data was initially displayed for less time, it is not restored.

How can I clear the terminal window from within a script, and prevent Terminal from restoring the cleared data?

I am running OS X 10.10.3.

  • Check my answer. If you need to view the output then there are other ways.
    – les
    May 19, 2015 at 3:41
  • I was unaware that text simply displayed in Terminal was written to disk. Doesn't closing the Terminal window clear anything that was displayed?
    – Stephen R
    May 19, 2015 at 4:18
  • @StephenR: No. Ever since Lion, the OS restores the window's previous contents...
    – ryebread
    May 19, 2015 at 4:24
  • There must be a setting that can be changed, because it doesn't do that on my system (OS 10.10 Yosemite). I ran some commands that had output to window. Quite Terminal. Started Terminal. New blank terminal window -- no content beyond the prompt.
    – Stephen R
    May 19, 2015 at 4:28
  • You might also try an alternate Terminal program, such a iTerm.
    – Stephen R
    May 19, 2015 at 4:29

3 Answers 3


Final Solution:

Remove the Terminal saved state, located in:

~/Library/Saved Application State/com.apple.Terminal.savedState/*

Then, make that folder read-only so that it can't be written to.

You can use the clear command to clear your terminal window from within a script. As noted on this other thread, the following commands in sequence will clear the current buffer, then the scroll back buffer:

clear && printf '\e[3J'

Please note:
(The clear command looks up the appropriate sequence for clearing the screen for the current terminal, but the “erase scroll-back” escape sequence is custom and must be hard-coded. If you put this in a shell script that you don’t know for certain will only ever be run with Terminal, you should check that $TERM_APPLICATION is Apple_Terminal before sending it.)

Alternative 1

Turn off Terminal.app's window restore functionality:

defaults write com.apple.Terminal NSQuitAlwaysKeepsWindows -bool false

Alternative 2

You can also store sensitive information in the Secure Notes section within the Keychain Access utility.

enter image description here

  • The clear command does not truly clear the terminal, it only outputs a bunch of new lines, and the previous output is readable if one scrolls up. I have tried your suggestion Alternative 1, without success (even after running this command, Terminal continues to restore my output). May 19, 2015 at 12:45
  • Yes, that is true about the clear command. However, when the window is closed and then restored, the scrollback is short enough that the output is no longer there to scroll up to. Alternately, have you tried turning scrollback off (set to 0 or 1 line) in the terminal window Preferences?
    – ryebread
    May 19, 2015 at 13:51
  • You could also remove the Terminal saved state: ~/Library/Saved Application State/com.apple.Terminal.savedState/* (and / or making that folder read-only so that it can't be written to.)
    – ryebread
    May 19, 2015 at 13:58
  • Deleting the contents of com.apple.Terminal.savedState and marking the directory as read-only prevents Terminal from restoring the output, so this solves my issue. Thank you. May 19, 2015 at 14:51
  • Separately, turning of scrollback and using clear did not seem to have an effect on the restore behavior. May 19, 2015 at 14:52

After reading the other answers and looking into this myself I have observed some file system behavior, which implies a very simple solution. The terminal program stores it's data in

~/Library/Saved Application State/com.apple.Terminal.savedState/

as noted above. When I quit the entire Terminal app (cleanly) this entire folder is deleted. The reason the OP is getting restored data is because he is crashing the terminal app with killall. I observed this by opening finder to the Saved Application State folder and starting and quitting terminal. The down side of this is that you have to close ALL terminal windows, but in this way all saved state appears to be wiped clean (baring disk forensics of course)

There appears to be one file in this directory for every open terminal window (but not every tab!) plus data.data and windows.plist and window_1.data that presumably represents the terminal program itself. The per-terminal files disappear on the closing of the window however the data.data file is the one that grows as commands are issued and thus presumably stores the scrollback buffer. It does not shrink on the closing of the terminal window implying that it continues to hold scrollback data. The data.data file does however shrink when the next terminal window is opened. It also shrinks drastically when another terminal window is updated (by pressing return for example). Thus it appears that the following routine will (probably) wipe the scrollback data completely:

  1. Cleanly close the window with the sensitive data (e.g. red dot, command + w)
  2. Open a new terminal window OR cause scroll in another terminal window that is already open.


  1. Close the entire terminal application cleanly (Command + q etc)

It's also worth noting that the data.data file is not a text file. It is a binary file that will require effort to interpret. My guess is that the data is compressed in some way. A simple cat of the file reveals nothing legible. So for these files to be a vulnerability, it seems both of the following must be true:

  1. Terminal has died and NSQuitAlwaysKeepsWindows is true (see other answer), or the terminal window was closed and no other window has been opened or updated.
  2. The attacker is sophisticated enough to know enough to look for and know how to decode the data.data file.

PLEASE NOTE: the above is based entirely on observation of how files appear/disappear and how their sizes change. It is of course still possible that some partial information is retained if the maintenance of the data.data file is sloppy. However these observations seem good enough for me. Decide for yourself if it's good enough for you.

These observations come from OS X 10.9.5 and Terminal Version 2.4 (326), please verify the above described behavior if you are using some other version before relying on this advice. Any or all of this could change with new versions of terminal or Mac OSX.

  • I have also noted that the data.data file may shrink when the window is manipulate (but none have been closed), implying a compression of data, however the shrinkage on update after closing a window is greater, and seems to be vaguely proportional to the relative size of the scrollback buffers among the windows. (Tested with a small buffer in one window and a very large buffer in another that I closed)
    – Gus
    Oct 19, 2015 at 15:25

try history -c and command + k


just send the output to /dev/null

If you need to view or store the output, then redirect it to a file for later use your_commands > path_to_filename/filename_where_output_is_stored

  • @JulianRosen in the script send the output to /dev/null That way there is no output to be restored
    – les
    May 19, 2015 at 3:39
  • To clarify, I would like to view the data. I do not want to write it (as plaintext) to a file, as this would allow anyone who had access to my computer to read it. May 19, 2015 at 3:55

You must log in to answer this question.

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