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

app.js の IDE 検出関数 kB() から始め、hft() と既存の b_o() liveness ヘルパーを比較します。oft()/yft() のソケットプローブの前にあるロックファイルのフィルタリングを追跡します。EPERM によって稼働中の workspace が破棄されなくなり、/ide が sandbox から到達可能な IDE を検出して接続できれば完了です。sandbox での再現とデバッグ出力を確認してください。

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.