reset or tput reset only does things to the terminal. The history is entirely managed by the shell, which remains unaffected.

history -c clears your history in the current shell. That's enough (but overkill) if you've just typed your password and haven't exited that shell or saved its history explicitly.

When you exit bash, the history is saved to the history file, which by default is .bash_history in your home directory. More precisely, the history created during the current session is appended to the file; entries that are already present are unaffected. To overwrite the history file with the current shell's history, run history -w.

Instead of removing all your history entries, you can open .bash_history in an editor and remove the lines you don't want to keep. You can also do that inside bash, less conveniently, by using history to display all the entries, then history -d to delete the entries you don't want, and finally history -w to save.

Note that if you have multiple running bash instances that have read the password, each of them might save it again. Before definitively purging the password from the history file, make sure that it is purged from all running shell instances.

Note that even after you've edited the history file, it's possible that your password is still present somewhere on the disk from an earlier version of the file. It can't be retrieved through the filesystem anymore, but it might still be possible (but probably not easy) to find it by accessing the disk directly. If you use this password elsewhere and your disk gets stolen (or someone gets access to the disk), this could be a problem.

The important thing to note here is the tag on the question. This behaviour is specific to GNOME Terminal and any other terminal emulators that are built upon libvte. You won't see this in Xterm, or in Unicode RXVT, or in the terminal emulator built into the Linux kernel, or on the FreeBSD console.

What happens in general is this.

1. The clear command looks at terminfo/termcap and issues appropriate control sequences.
   1. If the terminfo/termcap entry has an E3 capability it, it first writes out that. This issues control sequences to clear the scrollback buffer. This and the history behind it are documented in detail in the Dickey ncurses manual page for the clear command.
   2. It then uses the clear capability to clear the visible screen.
2. The control sequences in the terminfo/termcap entry are determined by the terminal type; but, with the exceptions of the (nowadays rare) terminals that use FormFeed to clear the screen (which DEC VTs and their imitators do not), they are either just plain old ECMA-48 control sequences or extensions thereto. For examples:
   • The putty entry defines E3=\E[3J which is the Xterm extension control sequence.
   • The NetBSD console's pcvtxx entry is one of many that define clear=\E[H\E[J or something similar. This is two ordinary ECMA-48 control sequences.
3. The terminal emulator acts upon the control sequences. As defined by ECMA-48 and the Xterm extension to it:
   • CSI H (CUP) homes the cursor.
   • CSI 0 J (ED 0) or just CSI J erases from the current cursor position to the end of the screen.
   • CSI 2 J (ED 2) erases the whole screen.
   • CSI 3 J (ED 3) erases the scrollback buffer.

When it comes to GNOME Terminal in particular:

1. The terminal type is properly gnome, but some people leave it erroneously set to xterm.
2. The gnome terminfo entry does not define an E3 capability, and on many systems — still! — neither does the xterm entry as this has not percolated down from Dickey terminfo. So clear just writes out the contents of the clear capability.
3. The contents of the clear capability for those terminfo entries are the control sequences to home the cursor followed by erase the whole screen.
4. But GNOME Terminal does not implement erase the whole screen correctly. More specifically, the library that it is based upon, libvte, does not do that in the code of its VteTerminalPrivate::seq_clear_screen() function. Rather, libvte scrolls the screen down an entire screen's worth of blank lines, and moves the cursor position to the first of those blank lines.

This is why you see what you see. libvte is not erasing the whole screen when told to. Rather it is doing something that has a superficial resemblance to that, until one does exactly what the questioner has done here: scroll the terminal window back to look at the scroll back buffer. Then the difference is blatant.

On other terminal emulators such as Xterm and Unicode RXVT, the ED 2 control sequence really does erase the screen, erasing every position on the screen in place, from the top down, and not altering the scrollback buffer. But on libvte terminal emulators, it just pushes the current screen up into the scrollback buffer and adds a screen's worth of blank lines. The prior screen contents are not erased but shifted into the scrollback buffer.

And if you run the clear command twice, it adds two screen's worth of blank lines. If your scroll back buffer is large enough, you can still find the original screen contents, simply further up in the scrollback buffer.

Further reading

• Control Functions for Coded Character Sets. ECMA-48. 1976.
• Georgi Kirilov (2007-12-30). Ctrl-L adds blank space to the scrollback buffer. GNOME bug #506438.
• To what extent are the xterm, xterm-color, and linux terminal emulators based on VT100?
• Clearing the "old" scrollback buffer
• Bash clear command weird behavior deletes scrollback buffer.
• https://superuser.com/questions/1094599/
• Thomas Dickey (2018). "Known Bugs in XTerm and Look–alikes: GNOME Terminal". XTerm Frequently Asked Questions. invisible-island.net.
• Thomas Dickey (2018). "Known Bugs in XTerm and Look–alikes: Notes on VTE". XTerm Frequently Asked Questions. invisible-island.net.