Dos bugs de Windows que parecían otra cosa: clic derecho en PowerShell admin y apps GUI 'invisibles'

TL;DR — Dos bugs de Windows cuyo diagnóstico “obvio” estaba mal. (1) El clic derecho no pegaba en la PowerShell de administrador: no era la app, era una subclave del registro que pisaba el ajuste global de QuickEdit. (2) Las apps gráficas lanzadas desde la terminal “no aparecían”: no era un problema de sesión de Windows, la ventana estaba fuera de pantalla y se recupera con ShowWindow + SetWindowPos.

Bug 1 — Que el clic derecho PEGUE en PowerShell (incluido “como administrador”)

El problema

Copias texto (por ejemplo de una consola donde corre Claude Code) y quieres pegarlo en una PowerShell abierta como administrador. Le das clic derecho sobre la ventana… y no pega. Tienes que hacer clic derecho sobre la barra de título → Modificar → Pegar. Cada vez. Insoportable.

La causa es la misma que la de copiar: el Modo de edición rápida (QuickEdit Mode) está apagado. Con QuickEdit activado, en la consola clásica el clic derecho pega (y seleccionar + Enter copia). Es una sola opción que arregla las dos direcciones.

Este post es el lado de pegar. El de copiar al seleccionar en todas las consolas tiene su propio artículo: Copiar seleccionando y pegar con clic derecho en TODAS las consolas de Windows.

Por qué pasaba justo en la de administrador

Windows guarda un perfil de consola por aplicación dentro de HKCU\Console. Existe una subclave específica para powershell.exe:

HKCU\Console\%SystemRoot%_System32_WindowsPowerShell_v1.0_powershell.exe

Esa subclave puede traer su propio QuickEdit apagado y sobrescribir el valor global. Por eso no basta con tocar el default: hay que forzar también las subclaves.

La solución (global, para todas las consolas nuevas)

Pega este bloque completo en PowerShell:

# --- Clic derecho pega + seleccionar copia, en TODAS las consolas clasicas ---

# 1) Default global
Set-ItemProperty -Path 'HKCU:\Console' -Name 'QuickEdit'  -Value 1 -Type DWord
Set-ItemProperty -Path 'HKCU:\Console' -Name 'InsertMode' -Value 1 -Type DWord

# 2) Forzar tambien cada sub-perfil por-aplicacion (incluye powershell.exe del admin)
Get-ChildItem 'HKCU:\Console' | ForEach-Object {
    Set-ItemProperty -Path $_.PSPath -Name 'QuickEdit'  -Value 1 -Type DWord -ErrorAction SilentlyContinue
    Set-ItemProperty -Path $_.PSPath -Name 'InsertMode' -Value 1 -Type DWord -ErrorAction SilentlyContinue
    Write-Host ('  perfil: ' + $_.PSChildName + ' -> QuickEdit=1')
}

# 3) Verificar
Write-Host ''
Write-Host ("Default HKCU\Console\QuickEdit = " + (Get-ItemProperty 'HKCU:\Console').QuickEdit)
Write-Host 'LISTO - abre una consola NUEVA para probar'

Cómo probar

1. Cierra la PowerShell admin actual y abre una nueva como administrador.
2. Copia cualquier texto de otro lado (Ctrl+C en un navegador, o de otra consola).
3. Haz clic derecho sobre la ventana de PowerShell → debe pegar de inmediato. ✅
4. De paso: arrastra el mouse sobre la salida para seleccionar y presiona Enter → queda copiado.

⚠️ El cambio aplica a ventanas nuevas. La consola donde corriste el script sigue igual hasta que la cierres y abras otra.

¿Y Windows Terminal?

Windows Terminal (el moderno, con pestañas) no usa HKCU\Console; usa su propio settings.json. Ahí el clic derecho ya pega por defecto y el copiar-al-seleccionar se controla con "copyOnSelect": true.

Bug 2 — “Las apps que lanza Claude no aparecen”: eran ventanas fuera de pantalla

El síntoma

Al lanzar una app gráfica (caso concreto: Tizen Studio, un Eclipse) desde la consola de Claude/Codex, había procesos java corriendo pero ninguna ventana visible. La conclusión previa fue:

“Los apps gráficos lanzados desde mi terminal no aparecen en tu pantalla; es un tema de sesión de Windows (quedan en otra sesión/bloqueados por UAC).”

Esa conclusión era falsa. Aquí está cómo se comprobó.

Paso 1 — ¿En qué sesión corre la terminal?

[System.Diagnostics.Process]::GetCurrentProcess().SessionId   # -> 1
query user                                                    # usuario  console  1  Activo

La terminal de Claude corre en SessionId 1, que es la misma sesión interactiva de consola del usuario. No hay aislamiento de sesión.

Paso 2 — Prueba de fuego: lanzar Notepad

Start-Process notepad.exe
Get-Process notepad | Select Id, SessionId, MainWindowHandle

El Notepad apareció en pantalla y tenía MainWindowHandle real. Conclusión: la terminal SÍ puede abrir apps gráficas que se ven. La teoría de la sesión queda descartada.

Paso 3 — Entonces, ¿qué pasaba con la app Java?

Revisando las líneas de comando de los procesos java:

Get-CimInstance Win32_Process | Where-Object { $_.Name -match '^javaw?\.exe$' } |
  ForEach-Object { "PID $($_.ProcessId): $($_.CommandLine)" }

Resultó que casi todos los java eran procesos de fondo de VS Code (servidores de lenguaje Red Hat Java, daemons de Gradle, el server de la extensión Oracle SQL Developer). Esos no tienen ni deben tener ventana.

El único que era una app gráfica fue Tizen Studio. Al inspeccionarlo:

$p = Get-Process -Id 58252
$p.Responding        # True   <- NO estaba colgado
$p.MainWindowHandle  # 791178 <- SI tenia ventana
$p.MainWindowTitle   # "workspace - Tizen Studio"  <- IDE cargado por completo

O sea: estaba abierto, respondiendo y con su ventana creada… pero la ventana estaba fuera de los límites del monitor (o en otro escritorio virtual). Por eso no se veía, y por eso relanzar tampoco servía (Eclipse bloquea el workspace con .metadata\.lock, así que un segundo lanzamiento no abre nada nuevo).

La solución: traer la ventana perdida al frente

No hay que cerrar ni reinstalar nada. Con el MainWindowHandle se restaura y se reposiciona a una coordenada visible usando user32.dll:

Add-Type @"
using System;
using System.Runtime.InteropServices;
public class Win {
  [DllImport("user32.dll")] public static extern bool ShowWindow(IntPtr h, int c);
  [DllImport("user32.dll")] public static extern bool SetForegroundWindow(IntPtr h);
  [DllImport("user32.dll")] public static extern bool SetWindowPos(IntPtr h, IntPtr a, int x, int y, int cx, int cy, uint f);
}
"@
$hwnd = [IntPtr]791178          # <- el MainWindowHandle de la app
[Win]::ShowWindow($hwnd, 9)                                   | Out-Null   # 9 = SW_RESTORE
[Win]::SetWindowPos($hwnd, [IntPtr]0, 100,100, 1400,900, 0x40) | Out-Null  # mover a 100,100
[Win]::SetForegroundWindow($hwnd)                            | Out-Null

Con eso, la ventana reapareció en la esquina superior izquierda. ✅

Versión genérica (buscar la app por título, sin saber el PID)

$p = Get-Process | Where-Object { $_.MainWindowTitle -like '*Tizen*' } | Select-Object -First 1
$hwnd = $p.MainWindowHandle
# ...luego el mismo ShowWindow / SetWindowPos con $hwnd

Lecciones (para no repetir el error)

1. La terminal de Claude está en la misma sesión que el usuario (Session 1). Las apps gráficas que lanza sí se ven. No culpar a “la sesión” por default.
2. Antes de dar por muerto un proceso, revisar Responding, MainWindowHandle y MainWindowTitle. Si tiene título de ventana, está vivo; el problema es de visibilidad, no de arranque.
3. Ventana invisible ≠ app colgada. Suele ser: minimizada, fuera de pantalla o en otro escritorio virtual. Se arregla con ShowWindow + SetWindowPos.
4. La mayoría de los java.exe/javaw.exe suelen ser servidores de fondo de VS Code y no deben tener ventana. No confundirlos con la app que se quiere abrir.
5. Para lanzar GUIs desde la terminal, usar Start-Process (PowerShell), no ./app.exe & desde Git Bash.