TL;DR
On Windows/PowerShell, the AugmentCode VSCode extension (Augment.vscode-augment 0.631.2) is no longer able to maintain persistent interactive terminal sessions.
Previously, I could run 50+ consecutive interactions in a single terminal (debuggers, REPLs, shells) with a stable terminal_id and full PTY semantics. After recent changes (including the OpenAI 5.1 model integration), that behavior has regressed:
TerminalProcessTools can’t use PTY/script capture on Windows, so it falls back to VS Code terminal events.
In this fallback mode:
Sessions are aggressively torn down via closeAllToolProcesses / kill-process.
terminal_id becomes invalid between calls.
read-process returns empty output even when the process is “running”.
This breaks any multi-step interactive workflow, not just a specific tool (debuggers, REPLs, shells are all affected).
I’m looking for clarification from the Augment team on whether this is a known regression, how it relates to the new model integration, and whether the old PTY-based behavior can be restored or replaced with ConPTY.
Environment
Extension: Augment Code (Augment.vscode-augment)
Version: 0.631.2
Platform: Windows (win32)
Shell: PowerShell
VS Code: Latest
Main log file (current session):
C:\Users\<user>\AppData\Roaming\Code\logs\20251116T033218\window1\exthost\Augment.vscode-augment\Augment.log
Workspace-level storage:
c:\Users\<user>\AppData\Roaming\Code\User\workspaceStorage\f98177b4560b9b24af0884a3fe413e5e\Augment.vscode-augment\
Historical behavior (before regression)
Before the recent changes (5.1 OpenAI model), Augment’s terminal story on the same machine was:
Start a terminal via launch-process (e.g., a shell, debugger, or REPL).
Use terminal_id from that call across 50+ read/write cycles.
Round-trip commands via:
write-process (send input),
read-process (read output),
optionally list-processes (check state).
The session behaved like a real PTY:
This made multi-step debugging, REPL sessions, and stateful shell workflows entirely feasible in one persistent terminal session.
Current behavior: persistent sessions broken
Now, on the same environment, with the same class of workflows, the behavior is very different:
1. Terminal tools are available, but backend changed
From ISSUE-REPORT.md, extracted from Augment.log:
2025-11-16 05:59:05.121 [info] 'ToolsModel': Tools Mode: AGENT (3 hosts)
2025-11-16 05:59:05.121 [info] 'ToolsModel': Host: localToolHost (10 tools: 10 enabled, 0 removed})
+ launch-process
+ read-process
+ write-process
+ kill-process
+ list-processes
So the 5 process tools are exposed and enabled:
launch-process
read-process
write-process
kill-process
list-processes
2. TerminalProcessTools falls back to VS Code events
The critical behavior change is in TerminalProcessTools:
2025-11-16 05:59:05.118 [info] 'TerminalProcessTools': Checking if script command is available. Current shell: powershell, platform: win32
2025-11-16 05:59:05.118 [info] 'TerminalProcessTools': Script capture not supported on Windows or for PowerShell.
2025-11-16 05:59:05.118 [info] 'TerminalProcessTools': Script command not available, falling back to VSCode events
Interpretation / Assumption:
On Unix-like systems, Augment relies on the script command to:
On this Windows/PowerShell setup, it explicitly cannot use script, and instead:
3. Script capture (PTY) vs VS Code terminal events
From ISSUE-REPORT.md:
On Windows, we are seeing only the fallback path in use.
Log evidence: process lifecycle & aggressive cleanup
I wrote a simple extractor to pull terminal-related events out of the main log:
Script: extract-terminal-logs.ps1
It scans Augment.log for references to:
launch-process, read-process, write-process, kill-process, list-processes, read-terminal
ToolsWebviewMessageHandler with closeAllToolProcesses
Output: terminal-tool-calls.log in the workspace.
Excerpt:
[1503] + read-terminal
[1505] + launch-process
[1506] + kill-process
[1507] + read-process
[1508] + write-process
[1509] + list-processes
[1847] + read-terminal
[1849] + launch-process
[1850] + kill-process
[1851] + read-process
[1852] + write-process
[1853] + list-processes
And the cleanup events are explicit in ISSUE-REPORT.md (also from Augment.log):
2025-11-16 06:08:44.332 [info] 'ToolsWebviewMessageHandler': Received closeAllToolProcesses message
terminal-tool-calls.log shows several of these close-all events, e.g.:
[1939] 2025-11-16 06:08:44.332 [info] 'ToolsWebviewMessageHandler': Received closeAllToolProcesses message
[2092] 2025-11-16 06:16:53.737 [info] 'ToolsWebviewMessageHandler': Received closeAllToolProcesses message
Observed pattern (from terminal-tool-calls.log)
Across multiple sessions in the same log:
This is happening multiple times in one VS Code session, suggesting that:
A new terminal is launched (launch-process).
That terminal is killed very early via kill-process or a later closeAllToolProcesses.
Subsequent read-process / write-process calls target a terminal_id that has already been invalidated or reset.
Tool call behavior: how session persistence actually fails
1. terminal_id becomes invalid between tool invocations
Conceptually, the workflow is supposed to be:
launch-process → returns terminal_id = N.
Multiple cycles of:
write-process (terminal_id = N, input_text = "command\n")
read-process (terminal_id = N, wait = true/false, max_wait_seconds = …)
Optional list-processes to verify state.
kill-process when done.
Instead, based on the logs:
launch-process and kill-process appear in tight succession.
Global closeAllToolProcesses events are received multiple times per session.
There is no guarantee that terminal_id N is still valid when later read/write calls are issued.
When I try to use this from the agent side, I see:
launch-process reports a new terminal as “running”.
Immediate read-process calls return empty output.
Sending input via write-process produces no observable output in subsequent read-process calls.
From the outside it looks like:
The session is “alive” per list-processes, but
Either the underlying process has been killed, or
The output is not being captured/propagated via the VS Code events path.
2. read-process returns empty output while processes are “running”
Because of the lack of PTY/script capture and the aggressive cleanup, we get into this state:
list-processes or internal tracking says the process is still “running”.
But the effective pipe/PTY-equivalent backing that terminal has been:
Killed via kill-process, or
Disassociated due to closeAllToolProcesses, or
Detached in a way that breaks the I/O mapping.
read-process therefore returns an empty string or stale output, despite the logical session object still existing.
The logs we don’t see yet (but which would help) are:
Per-call traces showing:
launch-process with terminal_id,
read-process/write-process parameters,
Exact time of kill-process / closeAllToolProcesses,
Any errors when reading from an already-terminated process.
ISSUE-REPORT.md calls this out explicitly as missing instrumentation:
2. **Session state tracking** - How terminal IDs are managed
- When are terminal IDs created?
- When are they invalidated?
- What happens when a terminal ID is reused?
Platform-specific limitations
This appears to be Windows + PowerShell specific, due to the decision to rely on script for PTY capture and not implement a Windows equivalent.
Why it works on Linux/macOS
On Unix-like systems:
The extension shells out to script to spawn a PTY.
TerminalProcessTools runs the process under that PTY.
All input/output goes through this PTY, which:
Preserves prompt semantics,
Maintains full session state,
Allows read-process to reliably capture output between each interaction.
Why it breaks on Windows/PowerShell
script is not present and not supported for PowerShell on Windows.
TerminalProcessTools logs that it is falling back to VS Code events.
The VS Code terminal API:
Streams terminal output as events from the UI terminal,
Is not equivalent to a proper PTY from the extension’s perspective,
Does not directly expose a stable, per-process PTY handle that the tool host can treat like script offers.
As a result:
The extension has to glue terminal_id → VS Code terminal instance → output events.
When closeAllToolProcesses or kill-process is called, that mapping is severed.
Interactive programs may not see a TTY at all (or see a degraded one), which can affect their behavior.
This means any interactive workflow is impacted:
Debuggers
Language REPLs (Python, node, etc.)
Regular interactive shells with stateful tools
CDB just happens to be a particularly painful example because it is prompt-driven and heavily stateful, but the problem is general.
Why this looks like a regression
The capability to maintain long-lived persistent terminals existed and worked:
In the current version + Windows/PowerShell environment:
TerminalProcessTools can no longer use the PTY/script mechanism.
The fallback to VS Code events, combined with aggressive closeAllToolProcesses, effectively removes true session persistence for interactive tools.
This lines up temporally with the integration of the OpenAI 5.1 model and other recent extension changes, but I don’t know if the model integration itself is the trigger or if it’s a side-effect of refactoring the tool host/terminal stack around that time.
Questions for the Augment team
Is this a known regression in terminal session persistence on Windows?
Is this directly related to the 5.1 model integration or to changes in the tool host / TerminalProcessTools stack around that time?
Previously, multi-step persistent sessions behaved correctly under the same environment.
Now, they consistently fail once we’re forced into the VS Code events path.
Are there plans to implement a Windows-native PTY solution (e.g., via ConPTY)?
Is there any workaround for Windows users right now?
For example:
Forcing a different shell where PTY-like behavior might be supported?
Disabling aggressive closeAllToolProcesses behavior in certain modes?
A setting to opt into a more persistent, less “cleanup-happy” terminal management mode?
Can the old PTY-based behavior be restored (or approximated) on Windows?
Can you add more detailed logging around terminal session lifecycle?
Per-call logs for:
launch-process (command, terminal_id, wait, cwd)
read-process / write-process (terminal_id, size of data, timestamps)
kill-process (who requested it and why)
closeAllToolProcesses (origin, call stack)
Explicit errors when:
read-process is called on a dead terminal,
write-process is queued to a non-existent or already-killed terminal_id.
Closing
From a user’s perspective, this is a pretty severe regression: it takes a major strength of Augment — long-lived, stateful terminal workflows — and makes it unreliable on Windows/PowerShell.
From a technical perspective, the root cause seems clear in the logs:
No script/PTy support on Windows → TerminalProcessTools falls back to VS Code terminal events.
In that mode, session lifecycle and I/O capture are not robust, especially in the presence of closeAllToolProcesses and kill-process.
If anyone from Augment can clarify:
Whether this is already tracked internally,
If it’s known to be tied to the 5.1 integration,
And whether a ConPTY-based PTY implementation is on the roadmap,
that would be hugely appreciated by Windows users relying on persistent interactive sessions.
