The WebSocket was closing exactly 100ms after switchToTerminal completed,
which correlated with the setTimeout(fitAddon.fit(), 100) call.
Hypothesis: The fitAddon.fit() call or the 100ms delay is causing
the WebSocket to close through an unknown mechanism (possibly triggering
browser GC, event loop blocking, or some resource cleanup).
Changes:
- Removed 100ms stabilization delay in launchCommand
- Disabled fitAddon.fit() call in switchToTerminal
This should prevent the WebSocket closure and allow commands to be sent.
The issue was that switchToTerminal() was not being awaited, so
launchCommand() was called while switchToTerminal() was still
executing. This caused a race condition where the WebSocket
closed before the command could be sent.
By awaiting switchToTerminal(), we ensure the terminal is fully
switched before attempting to send any commands.
- Log when switchToTerminal is called and if terminal is in map
- Log fitAddon.fit() execution with error handling
- Log when switchToTerminal completes
This will help identify if switchToTerminal is causing the WebSocket closure
- Added 100ms delay before sending command to ensure WebSocket stability
- Added detailed WebSocket state logging (CONNECTING, OPEN, CLOSING, CLOSED)
- Added bufferedAmount check to wait for pending sends
- Wrapped ws.send() in try-catch for better error reporting
- Split terminal and ws existence checks for clearer debugging
- Added debug panel in terminal view that shows all terminal activity
- Added debugLog() method to TerminalManager for consistent logging
- Updated connectTerminal, handleTerminalMessage, launchCommand, createTerminal, initializeXTerm with detailed logging
- Enhanced backend logging for WebSocket messages and close codes
- Logs now show both to console and visual debug panel
This should help diagnose the terminal command execution issue without
requiring browser console access.
Phase 1 of systematic debugging: Gather evidence
Added detailed logging to trace the complete command flow:
- launchCommand: Shows when called, terminalId, command, WebSocket state
- waitForTerminalReady: Shows waiting period and ready state
- handleTerminalMessage: Shows all messages from backend with details
- WebSocket message content logged before sending
Also fixed duplicate 'ready' message (removed line 113-116).
Now when user creates "Claude Code CLI" terminal, console will show:
1. launchCommand called with terminalId and command
2. Waiting for terminal ready
3. Ready message received (or timeout)
4. Command sent to WebSocket
5. All backend messages logged
This will reveal exactly where the flow breaks.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Implement proper ready-state handshake to fix command execution timing.
Root Cause:
WebSocket connection was opening immediately, but the backend PTY
(pseudo-terminal) wasn't ready to receive input yet. Commands sent
too early were lost, causing claude --dangerously-skip-permissions to
never execute.
Broken Flow:
1. WebSocket opens → connectTerminal() resolves immediately
2. Command sent → PTY not ready, command lost
3. Terminal shows cursor but Claude CLI never starts
Fixed Flow:
1. WebSocket opens → Wait for 'ready' message from backend
2. Backend sends 'ready' → PTY is now initialized
3. Command sent → PTY receives it successfully
4. Claude CLI starts
Changes:
- Add 'ready' flag to terminal state (default false)
- connectTerminal() now waits for 'ready' message before resolving
- Add waitForTerminalReady() helper with 5s timeout
- launchCommand() checks ready state before sending
- Enhanced error handling and console logging
Resolves: "terminal does not show or execute claude cli"
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Critical fix for completely broken terminal (blinking cursor, no input).
Root Cause:
The WebSocket was being connected before xterm.js was initialized,
causing the WebSocket reference to be lost because this.terminals
map didn't have the entry yet.
Broken Flow:
1. createTerminalUI() - Creates DOM elements only
2. connectTerminal() - Tries to store ws in terminal, but terminal = null
3. WebSocket reference lost immediately
4. No input/output possible
Fixed Flow:
1. createTerminalUI() - Creates DOM elements
2. initializeXTerm() - Creates xterm.js instance AND stores in map
3. connectTerminal() - Now finds terminal in map, stores ws successfully
4. switchToTerminal() - Terminal works!
Changes:
- Add explicit initializeXTerm() call before connectTerminal()
- Add error checking in connectTerminal() to verify terminal exists
- Add comments enforcing ordering requirements
Resolves: "All I see is blinging | and nothing else, no claude cli,
no commands, i cant type in anything. terminal is not woring."
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Make connectTerminal() return a Promise that resolves when the
WebSocket connection is established, ensuring commands are sent
only after the terminal is ready.
Root cause:
- connectTerminal() created WebSocket but returned immediately
- 500ms delay wasn't reliable - WebSocket might not be open yet
- Command was sent before connection was ready, causing it to fail silently
Fix:
- Wrap WebSocket creation in Promise
- Resolve Promise in ws.onopen callback
- Reject on ws.onerror
- Remove unnecessary 500ms delay
Now when "Claude Code CLI" terminal type is selected:
1. WebSocket connection is established
2. We wait for connection to be ready
3. Command is sent immediately
4. claude --dangerously-skip-permissions launches reliably
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
When launching Claude Code CLI with --dangerously-skip-permissions,
don't set the terminal mode to 'session' since we're not attaching
to an existing session. Keep it in 'mixed' mode instead.
The "Invalid session" error occurred because:
1. We launched claude --dangerously-skip-permissions without a session
2. Then set mode to 'session' which expects a valid session attachment
3. The CLI or backend rejected this as invalid
Fix: Remove the setMode call when using claude-cli terminal type.
Let the CLI create and manage its own session internally.
Resolves: "Invalid session" error when selecting Claude Code CLI
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Add CSS styling for the terminal type dropdown that was already
implemented in the JavaScript but wasn't visible due to missing styles.
The dropdown allows users to choose between:
- Standard Shell (bash/zsh) - default
- Claude Code CLI - runs claude --dangerously-skip-permissions
When Claude Code CLI is selected:
- Session picker is skipped (not needed)
- Terminal automatically launches with claude --dangerously-skip-permissions
- Mode is automatically set to 'session'
Changes:
- Add .terminal-type-selection, .terminal-type-select styles to terminal.css
- Match existing modal styling (background, borders, focus states)
- JavaScript was already implemented from previous work
Resolves: "Claude Code CLI still not appears under terminal > new terminal"
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Full IDE with terminal integration using xterm.js
- Session management with local and web sessions
- HTML preview functionality
- Multi-terminal support with session picker
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
·