Detent Point
How tabs and sessions share state
Our own test checklist got this wrong once, so it earns a full explanation.
The checklist item was named “multi-tab isolation.” Set $secret = 42 in tab A, read $secret from tab B, expect nothing. Tab B printed 42, and the tester marked a failure. Except the behavior was correct. Script tabs in the same session share a runspace on purpose, the way the ISE always did. What the item should have tested, session isolation, passes. We fixed the checklist wording and kept the lesson: if our own docs can blur the two layers, users will too.
So, plainly. DetentShell has script tabs and session tabs. Script tabs are editors. Every script tab inside one session shares that session’s engine: one runspace, one set of variables, one console. Run a script in one tab and its variables are visible at the prompt and to a run from the neighboring tab. This is what makes the console useful after F5. $results is still alive, and you can dig through it interactively.
Sessions are the isolation boundary. File, New PowerShell Session creates a separate runspace with its own console and its own script tabs. Nothing crosses between sessions. No variables, no modules, no state. The unit suite includes a test that sets a variable in one session and proves the other can’t see it.
The practical split: tabs organize files that belong to one piece of work, sessions separate pieces of work. Editing five scripts for one migration? One session, five tabs, shared helper functions and loaded data. Testing something destructive, or need a clean slate to reproduce a bug? New session, two keystrokes, total isolation.
There are limits on both, configurable in Settings: maximum open script tabs and maximum concurrent runspaces. Hitting a limit produces a message telling you exactly that, with the number, instead of letting the window degrade as tab forty-one opens. Closing a session’s last tab closes the session, with save prompts for anything dirty.
If you’ve been assuming tabs are sandboxes, the sharing will surprise you once. After that it tends to become the thing you rely on, because a debugger, a console, and three related scripts all seeing the same live state is most of what the word workbench means.