▣ wi

lezama ca.sh deploy: GCABA box - get Elazar explicit OK before nw-lezama-cc syncs; codex AGENTS.md convention (aro_join on start, cm/cms -> read_unread)

Ref

#576 (#576)

Project

llmmsg-srv

Parent

inProgress #572 ca.sh codex launcher: run codex on llmmsg-srv (ca= identity, sandbox-off, pull-only inbound, push-to-ccs) - fleet

Status

deferred

Priority

normal

Type

task

Assigned

pm-llmmsgsrv-cc

Created by

—

Created

2026-05-29T02:58:17.821Z

Updated

2026-06-04T15:56:19.304Z

Closed

2026-06-04T15:55:11.827Z

Sub-items

Questions

Event log

• 2026-05-29T02:58:17.822Z · created
  wi cli; parent=#572
• 2026-06-04T15:55:11.828Z · canceled
  Superseded by Elazar's 2026-06-04 directive: kill + delete the lezama codex (live sandbox-off full-access app-server daemon PID 1224 on the GCABA-restricted box - exactly the persistent non-GCABA workload lezama RESTRICTED policy forbids). #576 was 'deploy codex to lezama IF Elazar OKs'; Elazar ordered the opposite. Codex-bridge revival (#572/#634 t1-2) is whey-loopback (ws://127.0.0.1:8789), so no lezama codex is needed. Reopen only if Elazar reverses.
• 2026-06-04T15:56:19.304Z · statusChanged
  CORRECTION (was canceled): nw-lezama-cc kept the shared /usr/local/bin/codex CLI (active fleet-toolchain: ca/cfsa/cfresume/codex-update/llmlist/llmtop/title/oc) and only killed the rogue app-server daemon + trashed its unit (/etc/systemd/system/codex-app-server.service, RESTORABLE from Trash). So a lezama codex app-server is gated/disabled, not bricked. #576 stays DEFERRED: any lezama codex-agent deploy still needs explicit Elazar OK + a SUPERVISED non-dangerous config (the killed one was --dangerously-bypass-approvals-and-sandbox full-access, which violates lezama RESTRICTED). #572 core revival is whey-loopback and does NOT need this.
• 2026-06-05T06:51:54.640Z · note · wi-cli-whey
  Elazar explicit OK for lezama deploy 2026-06-05 (engineering DM). No longer blocked on approval; gated only on ca.sh landing in sh.git (#574). Then nw-lezama-cc syncs via sh.git pull.