fix(vscode): start Agent Manager terminals instantly - #12866
Conversation
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
| const [activePendingId, setActivePendingId] = createSignal<string | undefined>() | ||
| const [terminalFont, setTerminalFont] = createSignal<TerminalFont>({ | ||
| fontFamily: getComputedStyle(document.documentElement).getPropertyValue("--vscode-editor-font-family").trim(), | ||
| fontSize: readFontSize(), |
There was a problem hiding this comment.
SUGGESTION: Initial optimistic font uses the chat UI font size, not the terminal font size
readFontSize() reads --kilo-font-size-13 — the Kilo chat UI font scale (default 13, clamped to 10–24). That's a different setting from terminal.integrated.fontSize (default 14 on Linux/Windows, 12 on macOS, unclamped), which is what the extension host sends via agentManager.state / terminal.created. An optimistic terminal created before the first state message lands will paint at the chat font size and then visibly jump when the real terminal font is applied in TerminalTab's created handler. Low impact since the state message usually arrives first and the mounted xterm self-corrects — but if the goal is a stable first paint, consider seeding the signal with the platform terminal defaults instead (or a short comment noting the deliberate approximation).
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
| * tab back into the correct sidebar context. | ||
| */ | ||
| async create(params: { | ||
| terminalId: string |
There was a problem hiding this comment.
SUGGESTION: The create docstring is now stale
With this new parameter, the terminal ID is generated by the webview and echoed back, but the docstring above still says "Returns the attach info the webview needs: our synthetic terminal ID, …". Suggest updating it to note the ID is caller-supplied (e.g. "the webview-supplied logical terminal ID, echoed back").
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
Code Review SummaryStatus: 2 Issues Found | Recommendation: Address before merge Overview
The core design holds up well: the backend guarantees the 0x00 meta frame after replay on every attach, so the replay gate always opens; the input buffer is bounded (256KB per class); all new listeners and xterm subscriptions are disposed in Issue Details (click to expand)SUGGESTION
Files Reviewed (14 files)
Fix these issues in Kilo Cloud Reviewed by kimi-k3 · Input: 127.6K · Output: 39.5K · Cached: 3.3M Review guidance: REVIEW.md from base branch |
…rtup-performance fix(vscode): start Agent Manager terminals instantly
2 participants
Agent Manager terminal startup currently waits for extension messaging, PTY creation, and the initial WebSocket replay before mounting xterm. That makes Command+/ feel unavailable even though VS Code can create and focus its terminal UI before the shell process is ready.
This changes terminal creation to mount and focus an optimistic xterm immediately, reuse its logical ID when the PTY is returned, and buffer early input until the PTY replay boundary has been parsed. Terminal protocol replies remain ahead of user input, reconnects retain their existing recovery behavior, and terminal font settings continue to follow VS Code configuration.
Performance
Measured with the isolated VS Code self-test against the same Agent Manager worktree. The baseline measured time until the xterm input target could receive focus. The optimized flow measures the same milestone, plus the replay boundary and command output.
The result is an immediately typeable Agent Manager terminal while preserving shell startup ordering and cleanup for stale or failed creates. PTY startup remains asynchronous, but it no longer prevents typing or causes early input to be lost.