feat(desktop): ask consent on attach and take over a foreign runtime with the bundled CLI

[devin-ai-integration]

Summary

Windows validation of dev showed the desktop app attaching silently as a guest to a pre-running npm ocx proxy: no consent prompt, no service-state.json ownership record, and Quit left the npm runtime alive. The consent enum and recordServiceOwner existed but nothing wired them end to end (ownership::resolve was a None stub). This PR closes that loop.

CLI

• ocx resolve --json (schema unchanged, additive) now carries

  ownership: {kind:"none",revision} | {kind:"owned",ownership,revision} | {kind:"unknown",reason}
  takeover:  {kind:"supported",token,...} | {kind:"blocked",reason,detail,...}
  

  takeover is assessServiceTakeoverCompatibility fed by a new production observeManagingClis() (src/service/managing-cli.ts): probes --version of the CLI baked into the service registration and of the ocx found on PATH (in-module PATH/PATHEXT scan, cmd.exe /c for .cmd shims, never spawns process.execPath — the fix(cli): probe endpoint liveness in-process so the standalone resolve does not fork execPath #5418 rule). Ownership unknown stays exit 0; the shell fails closed on it.
• New ocx service claim --owner <cli|desktop> --install-id <id> (--expect-none | --expect-owner/--expect-install-id/--expect-generation) --expect-revision <n> --expect-compatibility-token <hex> [--json] → recordServiceOwner under the existing lock/lease with the exact approved subject + token; mismatch/unknown/compatibility-changed → exit 1 with {"schema":"ocx-service-claim/1","ok":false,"code":...}. Not gated by install checks (a takeover is not an install).

Desktop

• resolve.rs parses the new fields (missing → Unknown / Blocked, fail-closed). Recorded::{None,Owned} gain revision.
• On LiveVerdict::Attach, attach_plan(consent, takeover):
  • Held / Refuse / Blocked → guest as before, with the reason in the Attaching detail.
  • AskFirstTime / AskAgain + Supported → window is shown and the bootstrap page renders an in-page consent panel (no native dialog, per the page's own rule) with Port, Configuration home, Current owner and Take over / Stay a guest. The startup deadline is extended by however long the user takes.
  • Decline → guest. Approve → new phase Taking over the runtime that was already listening: bundled ocx stop --json → poll until the endpoint is silent (silence, not exit 0, is the receipt: on Windows a stop of a live runtime routinely exits 79 history-incomplete with the proxy already gone) → ocx service claim … --json → falls into the existing Starting/Waiting path. Stop still answering or claim refused → Failed with Retry.
• decide_takeover tauri command; Retry drops a pending prompt.
• Merged with dev's inline-script CSP fix: the consent JS lives in the index.html nonce script (main.js is gone). tests/clients/desktop-startup-surface.test.ts updated for the two intentional shape changes (let mut deadline, a fourth reportPageFailure( entry point).

Behavioural notes

• With a PATH ocx < 2.61.0 (e.g. the published npm 2.59.0), resolve reports takeover.kind = "blocked" (managing-cli-unsupported: …) and the app stays a guest with that reason — the existing compatibility contract. Takeover is offered once the PATH CLI is ≥ 2.61.0.
• Not in this PR: plain ocx start from an npm/standalone CLI does not consult the ownership record (it never did; only service install/uninstall and the updater do). Verified on Windows: with the desktop owner recorded and no runtime live, npm ocx start starts a runtime anyway. Whether ocx start should refuse for a foreign owner is a separate decision.

Verification

• bun run typecheck; bun test tests/cli/cli-resolve.test.ts tests/service/service-claim.test.ts tests/service/service-ownership-state.test.ts tests/clients/desktop-startup-surface.test.ts — 86 pass.
• desktop/src-tauri: cargo fmt --check, cargo clippy --all-targets -- -D warnings, cargo test — 80 pass.
• Windows Server 2022 / WebView2, MSI built from this branch at 664930183 (pre-merge, main.js still external; standalone CLI rebuilt → prepare-sidecar → build:local — the cached binaries/ocx-*.exe is otherwise stale), npm ocx 2.61.0 from this branch pre-started on 10100:

Consent panel (A)	Taking over (B)	Ready after takeover (B)

• Panel text: Port 10100; Configuration home C:\Users\Administrator\.opencodex; Current owner no recorded owner (an npm or standalone ocx install).
• A Stay a guest → Ready, npm PID 5492 unchanged, no ownership record; relaunch asks again.
• B Take over → npm PID gone, /healthz pid 1636 = ocx.exe child of opencodex-desktop.exe, service-state.json → ownership: {owner:"desktop", installId:<install-id file>, consentGeneration:1}, revision 1.
• C relaunch → no prompt, Ready. D no-proxy first launch → ordered checklist, Ready (no regression).
• Not exercised: the post-merge inline-script page on WebView2, blocked-takeover UI branch, re-consent against a different owner, forced claim failure / Retry.

Checklist

• Scope stays focused and avoids unrelated cleanup.
• Docs or release notes were updated when needed.
• Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults.

Review readiness checklist

This PR stays in draft until every box below is ticked. Tick all four boxes once the requirements are met:

• All CI tests are green on my local testing.

• I pushed my PR to the latest dev commit.

• I resolved all correct Codex and CodeRabbit findings.

• My PR is ready for review.

Link to Devin session: https://app.devin.ai/sessions/022ec1407f51490e8a2bd493ed310229
Open in Devin Desktop: https://app.devin.ai/desktop/session/022ec1407f51490e8a2bd493ed310229?variant=devin
Requested by: @lidge-jun

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository: lidge-jun/opencodex/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 7a7a5c7d-d362-4e5e-8c29-f088dedc9a1e

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

✅ Deterministic PR hygiene checks passed.

[github-actions]

⏳ DRAFT

• review readiness checklist open (2/4 boxes ticked).

What to do

• Tick all four boxes in the PR description once you're done (currently 2/4).

Review readiness checklist

• ✅ All CI tests are green on my local testing.
• ✅ I pushed my PR to the latest dev commit.
• ⬜ I resolved all correct Codex and CodeRabbit findings.
• ⬜ My PR is ready for review.

2/4 boxes ticked.

This PR stays in draft until every box above is ticked.

[lidge-jun]

리뷰 · 우선순위 64 / 80

이 PR은 데스크톱 앱이, 이미 켜져 있는 ocx에 묻지 않고 붙던 길을 고칩니다.

예전에는 앱을 켜면 먼저 떠 있던 npm ocx에 손님으로 붙었습니다. 주인 기록은 비어 있고, 앱을 꺼도 그 ocx는 남았습니다. 물어보는 구분과 주인을 적는 함수는 있었는데, 앱이 그걸 호출하지 않았습니다.

ocx resolve --json이 주인과 "가져가도 되는지"를 같이 돌려줍니다. 가져가도 되면 토큰이 붙습니다. 새 명령 ocx service claim은 그 토큰과, 동의할 때 본 주인 기록이 그대로일 때만 이 설치를 주인으로 적습니다. 기록이 바뀌었거나, 옆에 있는 ocx가 이 규칙을 모르면 거절합니다.

앱은 이미 듣고 있는 런타임을 보면 창을 엽니다. 포트, 설정 폴더, 지금 주인을 보여 주고 "가져가기"와 "손님으로 남기"를 둡니다. 가져가기를 누르면 앱에 들어 있는 ocx로 그 런타임을 멈추고, 포트가 조용해진 뒤에 주인을 적고, 이어서 앱의 런타임을 켭니다. 거절하면 예전처럼 손님으로 붙습니다. 주인 기록을 못 읽거나 가져가기가 막혀 있으면 묻지 않습니다.

베이스는 dev입니다. types.ts와 config.ts를 나누는 변경은 아닙니다. 같은 동작을 구현하는 다른 열린 PR은 없습니다. 5457은 인수 조건을 문서로 적는 PR입니다.

라인 desktop/ui/index.html 60 - 동의 글이 "이 앱을 주인으로 적으면 CLI가 옆에 런타임을 켜지 않는다"고 말합니다. ocx service start는 주인이 desktop이면 이미 거절합니다. 이 PR 설명은 터미널의 ocx start가 주인 기록을 보지 않고, 주인이 데스크톱이어도 런타임을 켠다고 적습니다. 버튼을 누르는 사람은 이 글을 읽습니다.

라인 desktop/src-tauri/src/startup.rs 741-760 - 멈춘 뒤 포트가 조용한지를 alive_within이 성공(Ok)이 아닌 것으로 봅니다. desktop/src-tauri/src/proxy.rs 149의 alive_within은 제한 시간이 먼저 끝나면 빈 값(None)을 돌려줍니다. 빈 값은 제한 시간이 끝났다는 결과입니다. 포트가 닫히면 에러가 납니다. 확인 도중 시간이 끝나면 루프를 나오고, 다음 확인도 빈 값이라 "아직 대답한다"는 실패로 가지 않습니다. 그 다음 주인을 적고 새 런타임을 켜려 합니다. 예전 프로세스가 포트를 아직 잡고 있을 수 있습니다.

라인 desktop/ui/index.html 239-244 - 버튼을 누르는 즉시 둘 다 잠급니다. decide_takeover 호출이 실패해도 잠금을 풀지 않습니다. 셸은 답을 계속 기다리고, 그동안 running이 켜져 있어 startup.rs 353의 begin은 다시 시작하지 않습니다. 재시도 버튼은 실패 단계에서만 나옵니다. 호출이 한 번 실패하면 이 창에서는 답을 보낼 수 없습니다.

라인 desktop/src-tauri/src/claim.rs 101-106 - 주인 기록을 못 읽은 경우에도 --expect-none과 리비전 0을 넣습니다. 주석은 이 갈래에 도달하지 않는다고 합니다. 지금 동의 판별은 못 읽은 기록에 묻지 않아서, 화면 경로에서는 타지 않습니다. 이 함수를 다른 곳에서 부르면, 못 읽은 기록을 "주인 없음, 리비전 0"으로 확인하는 명령이 됩니다.

메인테이너의 판단이 필요한 지점

터미널의 ocx start가 다른 주인일 때 거절해야 하는지입니다. 이 PR은 그 결정을 뒤로 미뤘는데, 동의 글은 이미 막힌 것처럼 말합니다. 런타임을 먼저 끄고 나서 주인 기록이 거절되면, 사용자는 꺼진 런타임과 빈 주인 칸을 만납니다. 그 순서를 유지할지도 정하면 됩니다. 준비 체크는 아직 2/4이고 PR은 초안입니다.

너의 추천

동의 글에서 "CLI가 옆에 런타임을 켜지 않는다"를 빼세요. 지금 맞는 설명은 "이 앱을 주인으로 적는다. 서비스로 켜는 시작은 막힌다. 터미널의 ocx start는 아직 그대로다"입니다. ocx start를 막을지는 5457과 맞춰 다음 변경에서 정하세요. 포트 확인은 연결이 실패한 경우만 조용하다고 보고, 시간 초과로 온 빈 값은 실패로 두세요. 버튼 호출이 실패하면 버튼을 다시 켜세요. claim.rs의 못 읽은 기록 갈래는 명령을 만들지 말고 실패로 두세요. 5457은 문서라 이 PR과 따로 두세요.

이 댓글은 grok-bot이 작성했습니다

[devin-ai-integration]

@lidge-jun 리뷰 네 지적 모두 c0c6dd2ba에 반영했습니다.

• index.html 동의 글: "CLI가 옆에 런타임을 켜지 않는다" 삭제 → "이 앱을 주인으로 적는다. ocx service start는 거절한다(src/service/cli.ts:321 확인). 터미널의 ocx start는 아직 막지 않는다."
• startup.rs take_over: 조용함의 근거를 Some(Err(_))(연결 거부)로만 인정. None(시간 초과)은 루프를 끝내고 "did not go silent before the deadline"으로 실패 → claim/spawn으로 넘어가지 않음.
• index.html decide(): decide_takeover 호출 실패 시 두 버튼을 다시 켭니다.
• claim.rs args: Option<Vec<String>> 반환, Recorded::Unknown → None. take_over는 "the recorded owner could not be read, so no claim was made"로 실패.

ocx start 소유자 거절 여부는 #5457과 맞춰 다음 변경에서 정하는 것으로 두었습니다. 런타임 stop 후 claim이 거절되는 순서는 유지했습니다(다음 실행이 "부재"로 시작하는 것이 안전한 종착점이라는 판단이며, PR 본문에 적어 두었습니다).

[lidge-jun]

Closing as superseded. The changes from this PR (head c0c6dd2ba4c8, by @devin-ai-integration) were carried with credit into #5564, which was consolidated into #5619. #5619 merged to dev as e964387. The carry was reimplemented as a squash with review repairs, not merged, so this branch's own commit history is not part of dev. I compared this head against current dev and found its behavior present, in some cases in revised form. Consent-based attach and foreign-runtime takeover, the attach plan, and the managing-CLI PATH resolution are present. #5619 added guarded-stop repairs. This closure does not assert acceptance of a real takeover on an installed platform, and the broader tracking issue #5443 stays open.

This is on dev only. It is not in the stable v2.63.0 release and will ship in a later release. Thank you for the contribution.