Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

/ide finds no workspaces under the CLI sandbox: kill(pid,0) EPERM misread as a dead process

Aberta Para iniciantes
  • Algo errado?
#4,909 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
78/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
javascript
Domínio
cli

Direção de pesquisa

Comece em app.js, na função de descoberta de IDE kB(), e compare hft() com o helper de liveness existente b_o(). Rastreie a filtragem do arquivo de lock antes da sondagem de socket oft()/yft(). Está concluído quando EPERM não descartar mais um workspace ativo, de modo que /ide descubra e se conecte à IDE acessível pelo sandbox; verifique a reprodução no sandbox e a saída de depuração.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

triage
Describe the bug

When Copilot CLI runs with its own sandbox enabled ("enabled": true), /ide always reports
"No active IDE workspaces found." — even though a compatible IDE is running, the lock file is
present and valid, and the IDE's MCP socket is reachable from inside the sandbox.

Running the exact same CLI version from the same directory outside the sandbox connects to the
IDE immediately.

Root cause

IDE discovery (kB() in app.js) filters lock files through a process-liveness check before it
ever probes the socket:

function hft(e){ try{ return process.kill(e,0), !0 } catch { return !1 } }
// ...
if(!hft(d.pid)){
  C.debug(`Skipping stale lock file (PID ${d.pid} not running): ${l}`);
  continue;
}

hft() swallows the error code and treats any throw as "process not running".

The bundled seatbelt profile (prebuilds/darwin-arm64/runtime.node) contains:

(allow signal (target same-sandbox))

The IDE process lives outside the CLI's sandbox, so it is not same-sandbox. process.kill(pid, 0)
therefore fails with EPERM, not ESRCH.

EPERM from kill(pid, 0) means "the process exists, but you are not permitted to signal it" —
i.e. the process is alive. It is the one error code that positively proves liveness. Treating it
as "dead" discards every lock file, and discovery returns zero entries before the socket probe
(oft() / yft()) is reached.

The CLI already has a second liveness helper elsewhere in the same bundle that handles this
correctly:

function b_o(e){
  try{ return process.kill(e,0), !0 }
  catch(t){ const n = t.code; return n === "ESRCH" ? !1 : n === "EPERM" }
}

So this is an inconsistency between two copies of the same check, not a design decision.

Evidence

Measured from inside the sandbox, against a live IDE lock file:

Step in kB() Result
read ~/.copilot/ide/*.lock OK — lock present, workspaceFolders matches cwd
hft(pid) → process.kill(pid, 0) throws EPERM (not ESRCH)
oft(socketPath, 250) socket probe connects in 0–2 ms — but never reached
curl --unix-socket <socketPath> http://localhost/ HTTP 404 (server alive and responding)

The debug lines this path emits when the sandbox is on (visible with debug logging enabled):

Skipping stale lock file (PID <pid> not running): <uuid>.lock
Discovered 0 IDE workspace entries

With the sandbox off, the same lock file yields (observed at default log level):

Connecting to IDE MCP server: IntelliJ IDEA (<workspace>)
Connected to IDE MCP server: IntelliJ IDEA
Affected version

GitHub Copilot CLI 1.0.86, macOS (darwin-arm64). Reproduced with JetBrains IDEs; the discovery code
is IDE-agnostic, so VS Code should be affected identically.

Steps to reproduce the behavior
  1. Open a project in a compatible IDE with the Copilot CLI integration, so that a lock file appears
    in ~/.copilot/ide/.
  2. Run copilot in that same directory with sandboxing enabled (I am using Anthropic SRT).
  3. Run /ide.
  4. Observe "No active IDE workspaces found."
  5. Re-run copilot with the sandbox disabled and run /ide again — the workspace is listed and
    connects.
Expected behavior

/ide should list and connect to the running IDE workspace regardless of whether the CLI is
sandboxed. Socket reachability — which already works under the sandbox — is the authoritative
liveness signal here.

Suggested fix

Treat EPERM as alive in hft(), matching the existing b_o() helper:

function hft(pid){
  try { process.kill(pid, 0); return true }
  catch (e) { return e.code === "EPERM" }   // EPERM => exists, not signalable
}

Two alternatives, either of which also resolves it:

  • Drop the PID pre-filter entirely and rely on the socket probe (yft/oft), which is a stronger
    liveness check and already sandbox-safe.
  • Widen the seatbelt profile to permit kill(pid, 0) against non-sandboxed PIDs — but the code-level
    fix is simpler and does not weaken the sandbox.
Notes

No user-facing sandbox setting can work around this: the (allow signal (target same-sandbox)) rule
is compiled into the runtime binary, and the network / filesystem / ignoreViolations config
keys do not cover signal delivery. The only current workaround is to run the CLI unsandboxed, which
is an unfortunate trade-off for a feature that otherwise works fine under the sandbox.

Linguagem predominante
Shell
Estrelas
11.2k
Forks
1.9k
Merge médio
17h 6min
PRs com merge (30d)
5

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de github/copilot-cli

Todas as issues de github/copilot-cli

Issues semelhantes

Mais issues de Shell/Bash

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.