Why your terminal is frozen and won't respond to keys — and what Ctrl+S has to do with it

You type a command — and nothing shows up. You hit Enter, again. Silence. The cursor sits there, letters don't appear, the $ prompt is gone. It feels like everything broke.
Almost always nothing broke. The terminal is either waiting for you, or you paused it yourself. Sometimes with the very shortcut you use to save a file in your editor.
Below are three causes nearly every beginner hits. We'll start with the most common one. For each: how to tell and how to fix it.
Cause 1. A command is waiting for your input
The most common case. You started a program, and it didn't hang — it's reading from the keyboard, waiting for you to type something.
Typical examples:
catorgrep errorwithout a file name. They wait for text straight from the terminal.- A script with a question inside:
npm init, "Continue? (y/n)". - A pager opened:
git log,git difformanshow text page by page. - A git commit without
-mopened an editor — Vim or nano.
How to check. Type a couple of letters. If they show up on screen but there's no $ prompt — the program is alive and waiting for input. A line with : or (END) at the bottom — that's a pager. Tildes ~ or hints like ^X Exit at the top or bottom — that's an editor.
How to fix. Pick the exit that fits:
Ctrl+C— interrupt almost any command.Ctrl+D— say "input is over." That's the clean way to endcat, interactivepython, and anything that reads until the end of input.q— quit a pager (less,git log,man).Esc, then:q!andEnter— quit Vim without saving. In nano —Ctrl+X.
A special case: you started a dev server like pnpm dev. It isn't supposed to give the prompt back — it runs until you stop it. Ctrl+C shuts it down. If you close the tab without Ctrl+C, the server may stay alive and hold the port — and that's a story about a port already in use.
Cause 2. An unclosed quote
You typed a command with a quote and forgot the second one:
git commit -m "fix login
You hit Enter — and instead of a result you see a > sign at the start of the line. Enter again — another >. Looks like a hang.
In fact bash is politely waiting for the end of the string. It sees an open quote and thinks you're writing multi-line text. The same happens with an unclosed bracket and with a heredoc whose end marker wasn't recognized.
How to check. The line starts with > instead of your usual prompt.
How to fix. Ctrl+C. The whole command is cancelled; nothing runs. Type it again with the quote closed.
Cause 3. You pressed Ctrl+S
The most unexpected one. You're used to hitting Ctrl+S to save a file. You pressed it out of habit in the terminal — and it froze. No letters, no reaction to Enter.
It's not a bug but a feature from the teletype era. In many Linux and macOS terminals, Ctrl+S means "stop output." The terminal stops showing anything on screen. Yet it still accepts everything: whatever you type afterwards piles up and waits.
How to check. Think back — did you press Ctrl+S? If there's no >, no pager, and letters get no reaction — it's almost certainly this. Whether this pause is enabled at all, stty -a | grep ixon will tell you: the word ixon without a minus means "enabled."
How to fix. Ctrl+Q — "resume output." The terminal thaws, and everything you typed spills out at once. Careful: if you panicked and typed commands and hit Enter, they'll run too.
To stop this from happening again, turn the pause off for good. Add a line to ~/.bashrc or ~/.zshrc:
stty -ixon
Where a text window got rules like these in the first place — see what is a TTY.
If nothing helped
Sometimes a program really is hung and ignores Ctrl+C. Then open a second tab and find it:
ps aux | grep program-name
kill 12345
Where 12345 is the process number from the second column. Didn't help — kill -9 12345. Crude, but reliable. The last resort is closing the terminal tab entirely.
What does [1]+ Stopped mean after Ctrl+Z?
Ctrl+Z doesn't close a program, it pauses it in the background. To bring it back on screen — the fg command. To close it — fg and then Ctrl+C.
Why did an AI agent "freeze" in the terminal?
Most often because of cause 1: a command asked a question and nobody is there to answer. Good agents add flags like --yes, but not always. Look at the last line of output — the question is usually there.
Short story-lessons, an agent simulator and daily practice — in our mobile app. Free.





