Sync failed: Refusing to write because ownership could not be proven: systemctl show exited 1: Failed to get D-Bus connection: No such file or directory.

[vebaev]

Client or integration

Codex CLI

Area

Proxy and routing

Summary

After installing latest version v2.24.2 the only original codex models remain and button Sync Now in the dashboard gives:

Sync failed: Refusing to write because ownership could not be proven: systemctl show exited 1: Failed to get D-Bus connection: No such file or directory.

Reproduction

Also the button for restart proxy not helped

Version

2.24.2

Operating system

Linux

Provider and model

No response

Logs or error output

Screenshots and supporting files

No response

Redacted configuration

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[chemcoder-2020]

I got the same bug after updating from 2.10.2.

[yzxcj797]

Root-caused the hard failure: on hosts where systemctl exists but no user session bus does (WSL, containers, systemd-less distros), systemctl --user show exits 1 with Failed to get D-Bus connection: No such file or directory, the systemd probe classifies that as unknown, and inspectNativeCodexOwnership turns it into "ownership could not be proven" — refusing every sync/write on such hosts forever.

Fix in service-manager-probe.ts, narrowly scoped so it doesn't touch the existing pinned semantics (Failed to connect to bus stays unknown — the user manager may genuinely be running there):

• the two "systemd user sessions are impossible on this host" messages — the missing session-bus socket and WSL's System has not been booted with systemd — now classify as absent, the same conclusion as spawnFailed (no user unit can be registered, so there is nothing to conflict with);
• every other non-zero status stays unknown exactly as before (and the existing test asserting that is untouched — a new test pins it).

Three new tests cover both absent messages and the unknown case. PR incoming.

[Ingwannu]

Confirmed: this is a real ownership-probe failure on hosts where systemctl exists but no user session bus is available. PR #2029 is aimed at the correct boundary, but its current head treats a missing bus as proof that no service definition exists. That can bypass the fail-closed ownership check when a unit file remains on disk, so I requested a revision that inspects and parses the unit file before allowing sync. Once that disk-evidence case and latest-dev rebase are covered, this remains a valid bug-fix candidate.

[lidge-jun]

리뷰 · 우선순위 66 / 80

대시보드 Sync Now가 Refusing to write because ownership could not be proven: systemctl show exited 1: Failed to get D-Bus connection: No such file or directory.로 거절한다. 카탈로그가 안 쓰여 원본 Codex 모델만 남는다. 재시작 버튼도 안 고친다. 설치 직후 기본 sync가 막혀 66이다. 환경(Docker/SSH/데스크톱)이 안 적혀 80은 아니다. #2114와 같은 프로브다.

거절 문구는 src/codex/admission.ts다. inspectNativeCodexOwnership()이 owned가 아니면 무단 쓰기를 거절한다. unknown일 때 리포터 메시지 그대로다. foreign이면 다른 문장이다. 주석도 답을 못 얻은 질문은 허가가 아니라고 한다.

unknown의 reason은 src/service-manager-probe.ts의 inspectSystemd()다. systemctl --user show가 spawn은 되고 exit 1이면 unknown("systemctl show exited ${status}: ${stderr}")다. stderr의 D-Bus 실패가 여기로 붙는다. #1612는 spawn 실패만 absent로 본다.

ownership-preflight는 manager.kind === "unknown"을 {ownership:"unknown"}으로 올린다. 서비스가 없는 foreground/컨테이너에서도 systemctl이 PATH에 있으면 질문이 버스에 던지지고 실패가 쓰기 거절로 승격된다. src/service.ts는 Docker에서 서비스 설치를 거절하지만, sync admission은 그 신호를 안 본다.

재시작이 안 고치는 이유도 #2114와 같다. 같은 프로브를 다시 돌려 같은 unknown을 얻는다. PATH에서 systemctl을 빼면 spawnFailed → absent → owned가 되어 sync가 통과할 수 있다. 그 우회는 환경 확인용이지 제품 답은 아니다.

해결방안

#2114와 같이 inspectSystemd()에서 버스 연결 실패(Failed to get D-Bus connection / Failed to connect to … bus)를 컨테이너/foreground 신호와 함께 absent로 본다. 데스크톱에서 버스가 잠깐 죽은 경우는 unknown 유지. unit 존재/NeedDaemonReload/홈 불일치는 fail-closed. admission.ts의 거절 문구는 그대로 두고 프로브 결과만 고친다. 리포터는 PID 1, /.dockerenv, systemctl --user show-environment 결과만 더 주면 된다. 토큰·홈 경로는 필요 없다.

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

[lidge-jun]

Fixed in v2.27.0, now on npm (@bitkyc08/opencodex@2.27.0).

The root cause was the one diagnosed in this thread: on hosts where systemctl exists but no user session bus does (WSL without systemd, containers, systemd-less distros), systemctl --user show exits 1 with Failed to get D-Bus connection: No such file or directory. The probe classified that as unknown, inspectNativeCodexOwnership turned it into "ownership could not be proven", and every sync/write was refused — so the catalog was never written and only the original Codex models remained.

Shipped in #2130 (b6b219c87, hardened by 82fd8106b). When the bus is unreachable, the probe now reads the unit file off disk instead. The disk needs no bus, and the homes a unit names are what ownership is actually decided on: no unit means nothing can own this home, so the write is allowed.

Worth stating what that fix had to avoid. With the bus down systemctl cannot see a foreign unit either, so "no answer" must not become "no owner". An audit caught exactly that — a first cut checked only ~/.config/systemd/user and reported owned on a host someone else owned. The shipped version walks every directory systemd itself honors, including the XDG_CONFIG_HOME and XDG_DATA_HOME overrides, and refuses rather than guessing when two units claim the proxy. Both your error string and WSL's System has not been booted with systemd are matched.

One limitation to know about. systemd localizes these stderr strings, so a non-English host will not match and keeps the old unknown. That errs toward refusing rather than wrongly admitting, which is the safe direction, but it means this may not reach you if your system messages are not in English. Forcing LC_ALL=C on the probe is the obvious follow-up.

If Sync Now still fails after upgrading, this pair identifies whether it is the locale gap or something else:

systemctl --user show opencodex-proxy -p LoadState -p FragmentPath 2>&1
ls -la ~/.config/systemd/user/opencodex-proxy.service ~/.local/share/systemd/user/opencodex-proxy.service 2>&1

Closing manually — PRs here target dev, so GitHub's auto-close does not fire. Reopen if it recurs.

Credit to @yzxcj797 for the root-cause analysis in this thread, and to draft PR #2029, which was working the same function first and agreed in direction.