Cowork Leaves Orphaned msedgewebview2.exe Processes Causing Total Input Failure

Resolved 💬 3 comments Opened Mar 13, 2026 by LWKOOT Closed Mar 17, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Bug Report: Cowork Leaves Orphaned msedgewebview2.exe Processes Causing Total Input Failure

Summary

Cowork leaves orphaned msedgewebview2.exe processes running after task completion or app closure. These processes hold low-level Windows input hooks that progressively corrupt keyboard and mouse input, eventually causing complete input failure requiring a full system reboot.

Environment

  • OS: Windows
  • Additional software: Logitech Options+ (keyboard/mouse driver)
  • Input devices: Bluetooth keyboard, USB dongle mouse

Symptoms

  • Shift key appears permanently pressed after Cowork runs
  • Mouse behaves as if Shift is held down (random text selection)
  • Caps Lock state becomes inverted
  • Progressive deterioration over time leading to complete keyboard and mouse failure
  • Affects ALL connected input devices (Bluetooth, USB dongle, and wired)
  • Only fully resolved by system reboot

Root Cause

When Cowork runs tasks and then closes (or crashes), it leaves a large number of orphaned msedgewebview2.exe processes running in the background with no parent process. These accumulate over time (30-39 orphaned processes observed in a single session). These processes hold low-level Windows input hooks that conflict with normal keyboard and mouse handling, eventually corrupting the entire input stack.

Aggravating Factor

Logitech Options+ keyboard/mouse driver adds an additional low-level input hook. The combination of Logitech's hook and Cowork's orphaned processes accelerates the failure.

Current Workaround

Manually killing all msedgewebview2.exe processes after each Cowork session using PowerShell:

Get-Process msedgewebview2 | Stop-Process -Force

Requested Fix

Cowork should cleanly terminate all child msedgewebview2.exe processes when a task completes or when the application closes, rather than leaving them running as orphaned processes.

What Should Happen?

Bug Report: Cowork Leaves Orphaned msedgewebview2.exe Processes Causing Total Input Failure

Summary

Cowork leaves orphaned msedgewebview2.exe processes running after task completion or app closure. These processes hold low-level Windows input hooks that progressively corrupt keyboard and mouse input, eventually causing complete input failure requiring a full system reboot.

Environment

  • OS: Windows
  • Additional software: Logitech Options+ (keyboard/mouse driver)
  • Input devices: Bluetooth keyboard, USB dongle mouse

Symptoms

  • Shift key appears permanently pressed after Cowork runs
  • Mouse behaves as if Shift is held down (random text selection)
  • Caps Lock state becomes inverted
  • Progressive deterioration over time leading to complete keyboard and mouse failure
  • Affects ALL connected input devices (Bluetooth, USB dongle, and wired)
  • Only fully resolved by system reboot

Root Cause

When Cowork runs tasks and then closes (or crashes), it leaves a large number of orphaned msedgewebview2.exe processes running in the background with no parent process. These accumulate over time (30-39 orphaned processes observed in a single session). These processes hold low-level Windows input hooks that conflict with normal keyboard and mouse handling, eventually corrupting the entire input stack.

Aggravating Factor

Logitech Options+ keyboard/mouse driver adds an additional low-level input hook. The combination of Logitech's hook and Cowork's orphaned processes accelerates the failure.

Current Workaround

Manually killing all msedgewebview2.exe processes after each Cowork session using PowerShell:

Get-Process msedgewebview2 | Stop-Process -Force

Requested Fix

Cowork should cleanly terminate all child msedgewebview2.exe processes when a task completes or when the application closes, rather than leaving them running as orphaned processes.

Error Messages/Logs

# Bug Report: Cowork Leaves Orphaned msedgewebview2.exe Processes Causing Total Input Failure

## Summary
Cowork leaves orphaned `msedgewebview2.exe` processes running after task completion or app closure. These processes hold low-level Windows input hooks that progressively corrupt keyboard and mouse input, eventually causing complete input failure requiring a full system reboot.

## Environment
- OS: Windows
- Additional software: Logitech Options+ (keyboard/mouse driver)
- Input devices: Bluetooth keyboard, USB dongle mouse

## Symptoms
- Shift key appears permanently pressed after Cowork runs
- Mouse behaves as if Shift is held down (random text selection)
- Caps Lock state becomes inverted
- Progressive deterioration over time leading to complete keyboard and mouse failure
- Affects ALL connected input devices (Bluetooth, USB dongle, and wired)
- Only fully resolved by system reboot

## Root Cause
When Cowork runs tasks and then closes (or crashes), it leaves a large number of orphaned `msedgewebview2.exe` processes running in the background with no parent process. These accumulate over time (30-39 orphaned processes observed in a single session). These processes hold low-level Windows input hooks that conflict with normal keyboard and mouse handling, eventually corrupting the entire input stack.

## Aggravating Factor
Logitech Options+ keyboard/mouse driver adds an additional low-level input hook. The combination of Logitech's hook and Cowork's orphaned processes accelerates the failure.

## Current Workaround
Manually killing all `msedgewebview2.exe` processes after each Cowork session using PowerShell:


Get-Process msedgewebview2 | Stop-Process -Force


## Requested Fix
Cowork should cleanly terminate all child `msedgewebview2.exe` processes when a task completes or when the application closes, rather than leaving them running as orphaned processes.

Steps to Reproduce

Bug Report: Cowork Leaves Orphaned msedgewebview2.exe Processes Causing Total Input Failure

Summary

Cowork leaves orphaned msedgewebview2.exe processes running after task completion or app closure. These processes hold low-level Windows input hooks that progressively corrupt keyboard and mouse input, eventually causing complete input failure requiring a full system reboot.

Environment

  • OS: Windows
  • Additional software: Logitech Options+ (keyboard/mouse driver)
  • Input devices: Bluetooth keyboard, USB dongle mouse

Symptoms

  • Shift key appears permanently pressed after Cowork runs
  • Mouse behaves as if Shift is held down (random text selection)
  • Caps Lock state becomes inverted
  • Progressive deterioration over time leading to complete keyboard and mouse failure
  • Affects ALL connected input devices (Bluetooth, USB dongle, and wired)
  • Only fully resolved by system reboot

Root Cause

When Cowork runs tasks and then closes (or crashes), it leaves a large number of orphaned msedgewebview2.exe processes running in the background with no parent process. These accumulate over time (30-39 orphaned processes observed in a single session). These processes hold low-level Windows input hooks that conflict with normal keyboard and mouse handling, eventually corrupting the entire input stack.

Aggravating Factor

Logitech Options+ keyboard/mouse driver adds an additional low-level input hook. The combination of Logitech's hook and Cowork's orphaned processes accelerates the failure.

Current Workaround

Manually killing all msedgewebview2.exe processes after each Cowork session using PowerShell:

Get-Process msedgewebview2 | Stop-Process -Force

Requested Fix

Cowork should cleanly terminate all child msedgewebview2.exe processes when a task completes or when the application closes, rather than leaving them running as orphaned processes.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

n

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗