@gotcos/glasses-server 7.0.30 → 7.0.34

package/.env.example

@@ -213,14 +213,16 @@ BIND_HOST=0.0.0.0
 # (glasses, phone, COS Control, Control Web). Question text only, never options or answers. It is
 # also written to the session-hook ledger on disk. Default ON; 0 restores 7.0.13's empty line.
 # COS_WAITING_QUESTION_WORDS=0
-# 7.0.16, both OFF by default: hold a session question (QUESTION) or a tool approval (APPROVAL) for
-# the whole hook wait, about an hour, so the glasses, the phone or Control Web can answer it even if
-# none was connected when it was asked. Only on engines proven to keep their own dialog up meanwhile
-# (Claude Code CLI 2.1.321+ in a terminal, Claude Desktop 2.1.317+); the Mac's dialog still shows at
-# once and the first answer wins. To turn on: set it here, restart the server, then COS Control >
-# Settings > Reinstall hooks. To turn off: remove it and restart (every held item goes back to the Mac).
-# Keep APPROVAL off for now: a signed-in Control Web browser could allow a tool for about an hour.
-# COS_QUESTION_FULL_HOLD=1
+# Hold a session question (QUESTION) or a tool approval (APPROVAL) for the whole hook wait, so the
+# glasses, the phone or Control Web can answer it even if none was connected when it was asked. Only
+# on engines proven to keep their own dialog up meanwhile (Claude Code CLI 2.1.321+ in a terminal,
+# Claude Desktop 2.1.317+); the Mac's dialog still shows at once and the first answer wins.
+# QUESTION, 7.0.34: ON BY DEFAULT, up to 8 hours, but only once COS Control > Sessions > Reinstall
+# hooks has written the 8 hour question hook; until then nothing changes. 0 turns it off (then
+# restart and Reinstall hooks); 1 turns it on outright. This line beats COS Control's setting.
+# APPROVAL: OFF by default (1 hour when on). Keep it off for now: a signed-in Control Web browser
+# could allow a tool for about an hour.
+# COS_QUESTION_FULL_HOLD=0
 # COS_APPROVAL_FULL_HOLD=1
 # 7.0.18, default ON (named by Miles 11/10): a Claude desktop session that ends its turn with a
 # question and reply buttons shows as waiting on the glasses, phone, Control Web and COS Control once

package/CHANGELOG.md

@@ -1,3 +1,208 @@
+## 7.0.34 - Questions can wait 8 hours, on by default (takes effect when you choose Reinstall hooks)
+
+2026-11-13. 7.0.33 plus one change, the 8 hour question hold on by default. Miles, 15:02: "I want the 8 hour question hold ON. please keep it on by default." Everything in 7.0.33 (and in 7.0.32, which never reached npm) is in this update too; see their entries below.
+
+**On for everyone, and what that means:**
+- **If you do nothing, one line is new; nothing else changes.** After updating, your Claude Code hooks, your questions' wait (about 10 minutes, and only while a device is with you), what reaches your browser and how you answer there are all exactly 7.0.33 with the switch off, and COS Control shows no banner. The one thing you see: Control Web's Sessions shows "Questions can now wait up to 8 hours. In COS Control on your Mac, choose Reinstall hooks." until this Mac's hooks are reinstalled (it does not show while the hooks have a problem, whose line already says Reinstall hooks). **Not now** at the end of the line puts it away in that browser; a browser that cannot store it shows the line again next visit. The lasting on or off is COS Control's setting or `.env`.
+- **If you choose Reinstall hooks** (COS Control on your Mac, Sessions; a newer COS Control offers it with one plain line), a Claude Code question waits up to 8 hours:
+  - it shows on Control Web and the glasses at once, even while you sit at the Mac;
+  - the Mac's own dialog stays up as before, and the first answer anywhere counts.
+  - Only sessions started after the click get it; a session already running keeps the hooks it loaded.
+- **ANY Install or Reinstall hooks turns it on for that Mac, a first install included.** A new Mac whose first step is Install hooks gets the 8 hour wait from day one.
+- **After Reinstall, answering from Control Web tightens, for approvals too:**
+  - every answer needs a recent touch on the page;
+  - an approval takes a tap, then a confirm;
+  - an item no device has been shown yet cannot be answered by its id (`not_shown`).
+  These are the 7.0.16 full-hold rules, which until now applied only with a switch on.
+- **How it is decided, per question:** a question gets the long wait only when its own hook asked for more than an hour. Only the question hook Reinstall writes asks for that (8 hours). An older hook asks for about 10 minutes and is treated exactly as before.
+
+**Turning it off:**
+- **`COS_QUESTION_FULL_HOLD=0`** in `~/.cos-glasses/.env`, then restart from COS Control and choose Reinstall hooks. `1` turns it on outright, as in 7.0.32.
+- **Or the new setting** a coming COS Control (0.5.394) writes: `PUT /api/session-hooks/question-hold` with `{"mode":"off"}`, `"on"` or `"default"`. It is the Mac app's only: a browser is refused, and Control Web shows the state only.
+- **The `.env` value wins over the setting.** It is what someone set on purpose at the Mac, and every release since 7.0.16 documents it as the off switch, rollback included, so a Settings click never undoes it. While it is set, the route writes nothing and answers `set_by_env`.
+
+**Rolling back from 7.0.34: switch off and Reinstall hooks FIRST.**
+- **Back to 7.0.33** with the 8 hour hook still in place: COS Control shows the "needs a refresh" banner (7.0.33 reads unset as off). A question is then held only while a device polls, at most about 10 minutes.
+- **Back to 7.0.31:** it does not accept the 8 hour stamp, so a question is held at most about 120 s until hooks are reinstalled under it.
+- **So, before any rollback:** `COS_QUESTION_FULL_HOLD=0`, restart from COS Control, Reinstall hooks. Then roll back, and Reinstall hooks once more under the older version.
+
+**A changed reading:** a value of `COS_QUESTION_FULL_HOLD` that is none of `1`, `true`, `on`, `0`, `false`, `off` (a typo, `yes`, `2`) used to read as OFF. It now reads as the default (on, pending Reinstall hooks). Use `0` to turn it off.
+
+**For developers:** `GET /api/session-hooks/status` adds `sessionHooks.questionWait`:
+- `{ mode, source, installedWaitS, waitS, active, offered }`;
+- `offered` is true when Reinstall hooks would turn the long wait on;
+- `state` is unchanged, so an older COS Control shows nothing new.
+
+**Not proven yet, said plainly:**
+- The 8 hour wait was measured only on Claude Code 2.1.321 and 2.1.322, overnight, with a stand-in hook. Claude Desktop's engine 2.1.317 to 2.1.320 was proven to 1 hour. Older engines keep the old rule.
+- The real COS server has never held a question for 8 hours end to end.
+- A Mac that sleeps while a question waits is untested.
+- Restarting COS ends any wait in progress; the question stays answerable in the Mac's own dialog.
+- Codex has no question hook, so its questions are unchanged. COS does not hold Cursor's questions.
+- The glasses show "480m left" for a new question until a glasses update says "8h left". The Mac's question card shows no time left.
+
+**Tested on this build** (the full suite on its parent 9f3bd8c2; this commit adds only these lines):
+- **The full server suite, alone:** 16,604 passed, 0 failed, type check clean.
+- **The Control Web layout checks in a test browser (WebKit):** the same results as 7.0.33, with nothing new failing.
+- **Not on a real phone, and the real server has not held a question for 8 hours end to end** (as above).
+
+**Tests:**
+- `server/lib/question-hold-default.test.ts`: never reinstalled equals switch-off at every layer; reinstalled is the full hold; 0 is off and 1 is on; the environment beats the setting; the route's refusals. The questions route keys are also pinned in `session-questions-queue.test.ts`.
+- Mutation gate `question-hold-default-mutation-gate.mjs`, one mutant per branch. The 7.0.16 full-hold gate's 14 stale targets are repointed: 5 had gone stale with 7.0.32's 8 hour change, 9 with this change. One is retired because 7.0.32 shipped its mutant on purpose.
+
+## 7.0.33 - Hotfix: a tap where Ask was could sign out every browser; plus Anand's second round of Control Web fixes
+
+2026-11-13. 7.0.32 plus a hotfix and Control Web fixes from Anand's second review. 7.0.32 never reached npm, so anyone updating from 7.0.31 also gets everything in 7.0.32 (listed below again).
+
+**The 8-hour question wait is still OFF** unless `COS_QUESTION_FULL_HOLD` is switched on, as in 7.0.32. With it off, a question waits about 10 minutes. Approvals wait 1 hour only with `COS_APPROVAL_FULL_HOLD` on.
+
+**The hotfix (7.0.31 and 7.0.32 have this fault).** On a phone, the top bar slides away as you scroll a list. Its strip then showed the page, so a tap meant for the bar landed on whatever was under it. On Settings that could be "Sign out every browser": two taps where Ask had been armed it, then signed out every browser. Reproduced with real taps at a 390 x 844 phone and at the folded Duo, against the published 7.0.31.
+
+**On for everyone, with no switch:**
+- **No tap falls through a hidden top bar.** While the bar is away, or for 320 ms while it slides back (also after a page change), the first tap in its strip only brings it back. The strip is the bar's own width, so the folded Duo's rail beside it still takes taps.
+- **Two-tap buttons expire.** Sign out every browser and Settings' Release stay armed for 5 seconds and the second tap counts only after 400 ms, the rule Today's and the question cards' buttons already use. A tap after 5 seconds arms again, even if the phone paused the page. Memories' two-tap buttons use the same 5 seconds (they used 6).
+- **The folded Duo, reading a message:** the top bar stays while you read and shows Back with the name of where it goes ("‹ Today"). The rail's Back stays too.
+- **A time under each message:** "You · 12:20 PM" under your question, and the answer's time under COS's answer. The server adds `queryTimestamp` (when the question was asked) to each message from `GET /api/sessions/today/all-messages` and the archive. With a server older than 7.0.33, only the answer has a time.
+- **Sessions, Usage and COS cost:** the three tabs sit in the same place on all three, and Usage's and COS cost's heading says Usage and COS cost, as the top bar does (it said Sessions).
+- **Today says each thing once.**
+  - A source that could not be read is named once, in the sentence. Needs you does not say it again.
+  - More than two sources unread reads "Your Mac is not answering, so this may not be everything." in the sentence.
+  - Needs you steps aside when it has nothing to add. Under a model summary it still says "Nothing is waiting on you."
+  - The Running card steps aside when nothing runs or the session list could not be read, and comes back when something runs.
+- **Ask:** when the words name a place, or its first three letters or more, Go to comes first ("usage" puts Go to Usage first).
+- **No machine codes on screen.** A server answer that is only a code now reads:
+  - `cos_pipeline_not_configured`, `pipeline_missing`: "This part of COS is not set up on this Mac, so there is nothing to show here. Nothing is broken." On Memories the box says "Not set up on this Mac.", with no Try again.
+  - `bridge_missing`: "COS on your Mac is set to use a scripts folder it cannot run, so this cannot be read. Check the COS_SCRIPTS_DIR setting on your Mac, then restart COS from the COS Control menu."
+  - `task_runtime_unavailable`: "Work is not set up on this Mac yet. Open COS Control on your Mac to finish setting it up."
+  - `unknown_command`: "COS on your Mac is older than this page. Update it from COS Control on your Mac."
+  - `bridge_error`: "COS on your Mac could not read this just now. Try again in a moment. If it keeps happening, restart COS from the COS Control menu on your Mac."
+  - any other code: "COS on your Mac could not do that just now. Try again in a moment. If it keeps happening, restart COS from the COS Control menu on your Mac."
+  - Memories: "Events in 90 days could not be counted" no longer shows when the list below already says it did not load.
+  - Sessions, hooks not installed: "COS cannot yet tell when a Claude Code session is working or waiting on you. In COS Control on your Mac, choose Install hooks."
+  - Sessions, hooks out of date: "COS’s link to Claude Code needs a refresh, so working and waiting may be out of date. In COS Control on your Mac, choose Reinstall hooks."
+  - Sessions, server too old: "Whether a session is working or waiting needs a newer COS on your Mac. Update it from COS Control on your Mac."
+- **No ⌘K hint on a touch screen** with no mouse (the open Duo, an iPad on its own). A desktop browser keeps it.
+- **The open Duo and wider screens: one way to get around.** Home and Settings left the bar at the top; the rail has Today and Settings.
+- **The trail (how you got here), the same rule at every size:**
+  - a place picked from the rail, the pane menu or Ask's Go to starts a new trail;
+  - steps are named by what they show, a meeting or session by its title and a message by "Message #N", cut to 28 characters with "…"; the kind ("Meeting") shows only until the title loads; Naming voices keeps that name;
+  - from 600 px the bar shows that trail ("Messages / Message #2"), no longer "COS Control › Messages › …".
+- **The pet: three choices** in Settings > Pet: On Today (the default; nobody's Today changes unless they pick), In the top bar, and Off.
+  - In the top bar, on a phone: a small round pet beside Ask on every page, keeping its own animation. A tap opens a card with the pet, what it is doing, "I’ll wave when an agent starts." when nothing runs, Change pet and Hide.
+  - Hide turns the pet off and says "Pet hidden. Turn it back on in Settings, Pet." The card never covers a banner's button.
+  - On the folded and the open Duo the pet stays on Today for now.
+  - The Mac's own pet is not changed.
+
+**From 7.0.32, also on for everyone (never on npm before this):**
+- the waiting-questions route's `queue` and `queueCount`;
+- a question asked at the end of a turn survives a server restart for its full 8 hours;
+- an answer records which app gave it;
+- the server keeps up to 400 session titles in memory;
+- one new line in the session hook script;
+- the glasses pair by the typed code alone, so no server message says scan (two pairing messages changed);
+- the browser sign-in box takes the glasses' 14-character code;
+- a waiting question's time left reads hours and minutes past an hour.
+
+**Tested on this build** (the full suite on its parent 837fb6f0; this commit adds only these lines):
+- **The full server suite, alone:** 16,574 passed, 0 failed, type check clean.
+- **The tap-through, with real taps in a test browser (WebKit):** two taps where Ask was signed out every browser on the published 7.0.31 (a 390 x 844 phone and the folded Duo); on this build 15 of 15 checks pass, and a tap on the folded Duo's rail still lands.
+- **The Control Web layout checks against 7.0.32:** the same results as 7.0.32 (16 in the narrow-and-folded matrix and one short-page check fail as in 7.0.30). Changed on purpose: the folded Duo reader draws Back in its top bar, the bar from 600 px has no Home or Settings, and the trail names steps by title.
+- **Not on a real phone.**
+
+**Not in this release:** Work's Filter button and the one refresh control with pull to refresh (both wait for Miles's pick, for 7.0.34), and the pet's place on the Duo.
+
+### If you roll back
+
+- To 7.0.32: taps can fall through the hidden top bar again, the two-tap buttons stay armed with no limit, messages have one time, Today repeats a failure, Ask lists Go to last, codes can show on screen, ⌘K shows on touch, the bar has Home and Settings, the trail names steps by kind, and the pet has only on and off (a pet set to the top bar shows on Today).
+- To 7.0.31: also as in 7.0.32's rollback below.
+
+## 7.0.32 - Questions can wait 8 hours (off unless switched on), one queue of waiting questions, code-only glasses pairing words, and the sign-in box takes the glasses code
+
+2026-11-13. 7.0.31 plus three pieces: X1's question wait, W1's pairing words and sign-in field, and one Control Web label.
+
+**The 8-hour question wait is OFF.** With it off, a question waits about 10 minutes, as before. It turns on only when `COS_QUESTION_FULL_HOLD` is switched on. On 11/12 at 20:17 neither switch was set anywhere on Miles's Mac.
+- **To turn it on:** set `COS_QUESTION_FULL_HOLD=1` in `~/.cos-glasses/.env`, restart the server, then choose **Reinstall hooks**. The installed hook keeps its old wait, and shows the Reinstall banner, until then.
+- **With it on:**
+  - a question Claude asks waits up to 8 hours, and can be answered from the web, the glasses or the Mac;
+  - it shows on all of them at once;
+  - the first answer wins, and it stays everywhere until answered.
+- **Approvals** wait 1 hour only with `COS_APPROVAL_FULL_HOLD` on (also off), otherwise about 10 minutes.
+The 8 hours was measured on a real engine: a hook held 7 h 55 m and its answer was applied.
+
+**On for everyone, with no switch:**
+- **The waiting-questions route gains a queue.** `GET /api/session-questions` adds `queue` and `queueCount`, one list of every question or approval waiting anywhere, with answered ones for two minutes. No current client reads them yet.
+  - A waiting question's entry carries its first 80 characters only, as sessions already do (off with `COS_WAITING_QUESTION_WORDS=0`).
+  - Approvals waiting only at the Mac, and answered entries, carry no words.
+- **A question asked at the end of a turn survives a server restart for its full 8 hours.** Before, one asked 6 to 8 hours before a restart was lost.
+- **An answer records which app gave it** (web, glasses, phone or Mac), from the app's own label. It is a label for the queue, not proof of who answered.
+- **The server keeps the titles of up to 400 sessions in memory**, filled by the session list, so the queue can name them.
+- **The session hook script carries one new line.** A hook installed by 7.0.31 still counts as installed. Nothing asks to reinstall it; it matters only after a Reinstall.
+- **The glasses pair by the code alone, so no server message says scan.** Signing a browser in by QR is unchanged, and Control Web, its Settings and the sign-in page already had no such line. Two messages the glasses app shows changed:
+  - a pairing request that was not understood: "That pairing request was not understood. Scan the code again." becomes "That pairing request was not understood. Check the code in COS Control and type it again." The parity copy `docs/pairing-fixture.json` changes with it.
+  - a request without the pairing token: "Paste the pairing token from COS Control, or scan its code with COS Glasses 6.10.621 or newer." becomes "Paste the pairing token from COS Control, or update COS Glasses and type the pairing code COS Control shows." Clients act on its reason, not its words.
+- **The browser sign-in box takes the glasses' full 14-character code** (17 keys with its dashes; it took 9 before). Typed with or without dashes, it says it is the glasses code. It is recognised by its shape, never looked up, and nothing is used up. A real 8-character sign-in code works as before.
+- **Control Web: a waiting question's time left reads hours and minutes past an hour**, for example "7 h 59 m left", where an 8-hour question would have read "480 min left".
+
+**Not in this release (X1's other two asks for Control Web):**
+- the Today count, the Sessions rail and the pet reading the shared queue;
+- "Answered on <app>" on a card answered elsewhere.
+Both are for a later release, before the 8-hour switch is ever turned on.
+
+**Tested on this build** (the full suite on its parent 90453233; this commit adds only these lines):
+- **The full server suite, alone:** 16,543 passed, 0 failed, type check clean.
+- **The Control Web layout checks, in a test browser (WebKit) against 7.0.31:** every check passed except 16 in the narrow-and-folded matrix and one known short-page check, all of which fail the same way in 7.0.30.
+- **The sign-in box:** 17 typed keys reach the server (7.0.31 kept 9).
+- **Not on a real phone.**
+
+### If you roll back
+
+- To 7.0.31: no queue fields, a turn-end question older than 6 hours is lost on a restart, the sign-in box takes 9 characters, the two pairing messages say scan again, and the time left reads in minutes. A question waits about 10 minutes, as it did in 7.0.32 unless the switch was on; a hook reinstalled with the switch on keeps its longer wait until it is reinstalled again.
+- Further back: as in 7.0.31 below.
+
+## 7.0.31 - Control Web: a message's text no longer runs under and below Reply on a wide screen
+
+2026-11-12. A hotfix to 7.0.30, nothing else in it.
+
+- **7.0.30 shipped this fault.** On a wide screen (the open Duo, an iPad, a desktop browser), a message's text could run behind and below the pinned Reply box. The top bar was gone, and the left rail started partway down its list and ended partway down the screen. Miles saw it on the open Duo at 17:25 and could not make it happen again. It came from 7.0.30's Reply staying at the bottom of the screen.
+- **The cause.** The message reader was the whole page. Its Reply box was pinned to Safari's idea of the screen, and the rail was as tall as that idea. On his Duo, typing a reply moved Safari's view about 409 px down the page, as a keyboard does, so the field stays in sight. After the keyboard closed, he folded and unfolded the Duo five times. Safari then reported its visible area as 0 px tall, then as a large negative number, with its top still about 409 px down. The view stayed shifted, and Reply and the rail stopped about halfway down the screen, with the rest of the message painted below them. It needs that keyboard-then-fold sequence, which is why it came and went. No part of the page was too tall for its box.
+- **The fix.** From 600 px wide, an open message is now one screen, the way Sessions already is. The rail and the area under the top bar each scroll by themselves, and the page itself no longer scrolls. The sign-in notice, a question card and the message still scroll together, as in 7.0.30, and Reply stays at the bottom of that area. At the end of a message, the Reply section sits just above the Reply box, with nothing under it. With the keyboard up, the box sits above the keyboard as before. The screen's height comes from the page's own measurement, which falls back to the window's height when Safari's reading is broken.
+- **What 7.0.31 does and does not fix.**
+  - **Fixed:** it stops the message showing behind and below Reply.
+  - **Not fixed:** Safari leaving the page pushed down after the keyboard and a fold. If that happens again, the app can sit shifted, with a blank band at the bottom of the screen and the top bar out of sight. It returns to the full screen when Safari's view moves back, for example on the next fold, rotation or keyboard. In a browser test, the page refilled the screen after a resize, with no reload.
+  - **Not done:** the page does not follow Safari's reported position. On his Duo that reading was 40 to 85 px off while the height read 0.
+  - **What's next:** we now record Safari's readings on every message opened, every fold and every keyboard close, to find out how often it happens.
+  - **Seen once in the readings we have:** today, from 07:42, the only stranded push came after a keyboard in the message reader. After five keyboard uses in Sessions and one in the COS chat, which were already one screen, every following reading was back at the top, through folds that broke the height readings the same way. One day of readings proves nothing either way.
+- **On the open Duo with a question card showing**, a short message's Reply box starts just below the bottom of the screen, as in 7.0.30. The page stays one screen, and scrolling the message brings Reply up.
+- **Folding or unfolding while reading keeps your place.** A fold or an unfold moves the message between the page's own scroll (narrow) and the framed area (wide). On its own the new view would open at the top, so the line you were reading is put back at the top, once, after the fold. It waits until your finger is off the screen and the page is still. If you scroll first, your scroll wins and it does nothing. Nothing else moves the text: not the keyboard, not Safari's bars, not a question card or notice appearing.
+- **Phones and the folded Duo otherwise unchanged.** Under 600 px, with no fold, the message reader works as in 7.0.30, with the side rail on the folded Duo.
+- **The Reply section stays.** The "Reply. Continues this conversation" block above the box is where replies sent from that message appear. It is not a second Reply box.
+- **The rest of the app in the same Safari state** (Today, the Messages list, Meetings, Speakers, Work and Settings, at 600 px and wider): no pinned part has text under it, but the rail can end partway down with the page continuing below it. Sessions already stays inside one screen. Those panes are not changed in this hotfix.
+- **New numbers in the page's own layout reports**, numbers only, to the Mac's diagnostics log:
+  - the height of 100dvh at each fold;
+  - for every message opened, at any width: the visible area, the message's box, the scrolling area's height and content height, where Reply sits, the page's height and scroll, and 100dvh. The page already sends the window's size and Safari's visible area with each report, so a shifted view shows as its top.
+  The 17:25 frame could not be measured; the next one will be.
+- **Tested in a browser (WebKit)**, in light and dark:
+  - **His two Safari states, recreated:** the view shifted 409 px, and a window 430 px tall drawn 787 px tall. 7.0.30 paints text below Reply in both; this build paints none.
+  - **A long message at seven sizes:** a tall iPhone, the folded Duo at 85% zoom, 1000x703, the open Duo at 1119x787 and 951x539, an iPad at 1180x820, and a desktop at 1440x900. 7.0.30 fails 20 of 48 of these checks; this build passes all 48.
+  - **The Sessions check list on the message reader:**
+    - typing with the keyboard up, with two files attached;
+    - folding and unfolding without a reload;
+    - Back while reading, and the how-you-got-here line on a phone;
+    - the browser's find, and selecting text;
+    - the question card;
+    - a short message and a 14,000 px message;
+    - the scroll position kept when the page refreshes the same message.
+
+    These ran at 951x539 and 1119x787 at 85%, 382x557, 449x797, 1180x820 and 1440x900. The keyboard was simulated by shrinking the window, the way an Android keyboard does; an iPhone keyboard shifts the view instead, which was not simulated. A reply arriving while you read was not driven.
+  - **Not yet:** a real phone. This counts as done only when Miles has looked at it on the Duo.
+
+**Default-on for every install:** yes, with no switch, two things: on screens 600 px and wider, an open message is one screen and the area under the top bar scrolls instead of the page; and an open message keeps your reading place across a fold or an unfold. Nothing else changes under 600 px.
+
+### If you roll back
+
+- To 7.0.30: an open message is the whole page again, and after the keyboard and folds its Reply box and the rail can stop partway down the screen with the message below them. A fold or an unfold moves you a few paragraphs back.
+- Further back: as in 7.0.30 below.
+
 ## 7.0.30 - Control Web: Back goes the way you came, a phone shows how you got here, a message shows who said what, Reply stays at the bottom, Meetings opens on today, and clearer copy buttons
 
 2026-11-12. 7.0.29 plus eight Control Web changes from a tester's phone feedback, one clearer sign-in error, and phone-approval changes that stay off unless switched on.
@@ -23,6 +228,8 @@ Server:
 
 **Default-on for every install:** yes, all eight, with no switch, at every screen size (the how-you-got-here line below 600 px only). The sign-in line is on for everyone. The phone-approval items do nothing while the switch is off, which is the default everywhere.
 
+**Known fault, fixed in 7.0.31:** on a wide screen, after the keyboard and then folds on the Duo, a message's text could run behind and below the pinned Reply box. 7.0.31 stops that. Safari can still leave the page pushed down after the keyboard and a fold; 7.0.31 does not fix that and records it when it happens.
+
 ### If you roll back
 
 - To 7.0.29: Back goes to a fixed parent again, the top bar tucks away on a reader, the message reader's Reply is at the end of the page, the copy buttons say Summary and Full, Meetings opens on today only when today has meetings, Settings says iPhone, a message shows the YOU and COS cards, the how-you-got-here line is gone, and an expired Claude sign-in reads "provider process exited" again. Nothing is stored.

package/bin/hooks/cos-session-hook

@@ -150,11 +150,12 @@ case "$(head -c 1 "$T.in")" in '{') ;; *) EVENT=rejected ;; esac
 # 6.60.0: the installer passes the PermissionRequest block's own timeout as $2. Claude Code
 # stops this hook at that many seconds, so curl below gives up 5 s before it, and the
 # request carries it (`hookWaitS`) so the server never holds it longer. No usable $2 (an
-# earlier block) is the earlier wait, 130, with no stamp.
+# earlier block) is the earlier wait, 130, with no stamp. X1: up to FULL_HOLD_QUESTION_WAIT_S (28800, 8 h;
+# server/lib/full-hold.ts), the full hold's question block; a test pins this line to that constant.
 WAIT=130; STAMP_WAIT=''
 if [ "$EVENT" = PermissionRequest ]; then
   case "${2:-}" in ''|0*|*[!0-9]*) ;; *)
-    if [ ${#2} -le 4 ] && [ "$2" -ge 20 ] && [ "$2" -le 3600 ]; then WAIT=$2; STAMP_WAIT=",\"hookWaitS\":$2"; fi ;;
+    if [ ${#2} -le 5 ] && [ "$2" -ge 20 ] && [ "$2" -le 28800 ]; then WAIT=$2; STAMP_WAIT=",\"hookWaitS\":$2"; fi ;;
   esac
 fi
 # 6.71.x: only a correctly read question from the new script skips the desk fast path.

package/docs/pairing-fixture.json

@@ -65,7 +65,7 @@
     "draining": 503
   },
   "reasonMessages": {
-    "bad_request": "That pairing request was not understood. Scan the code again.",
+    "bad_request": "That pairing request was not understood. Check the code in COS Control and type it again.",
     "not_loopback": "Pairing codes are made only by COS Control on this Mac.",
     "not_allowed_network": "Connect over Tailscale, or turn on \"Allow pairing on this Wi-Fi\" in COS Control.",
     "denied": "Pairing was denied on the Mac.",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gotcos/glasses-server",
-  "version": "7.0.30",
+  "version": "7.0.34",
   "description": "COS Glasses: self-hosted AI heads-up-display server for Even G2 smart glasses, powered by Claude Code, Codex, Cursor Agent CLI, or local Ollama",
   "type": "module",
   "bin": {
@@ -155,6 +155,8 @@
     "!server/scripts/compact-session-log.ts",
     "!server/scripts/full-hold-mutation-gate.mjs",
     "!server/scripts/turn-end-ask-mutation-gate.mjs",
+    "!server/scripts/question-8h-mutation-gate.mjs",
+    "!server/scripts/question-hold-default-mutation-gate.mjs",
     "docs/web-key-verifier-contract.md"
   ],
   "author": "COS Contributors",

package/server/index.ts

@@ -58,6 +58,7 @@ import {
 import { createPermissionBrokerHookRouter, createSessionQuestionsRouter } from './routes/permission-broker.js'
 // X1: the full hold's switches and the engine gate's registry read (kept on their own lines, apart from other lanes' imports).
 import { fullHoldSwitches } from './lib/full-hold.js'
+import { readQuestionHoldSetting } from './lib/question-hold-setting.js'
 import { engineForHookProcess, registryStatusForPid } from './lib/full-hold-engine.js'
 import { lastHoldQuestionsPollAt, lastLegacyQuestionsPollAt, lastQuestionsPollAt, presenceAgeMs, webPresenceAgeMs } from './lib/client-liveness.js'
 import {
@@ -377,8 +378,9 @@ const permissionBroker = new PermissionBroker({
     return !!signal && !signal.ended && signal.waiting?.fingerprint === fingerprint
   },
   signals: brokerSignalSink(sessionSignalStore),
-  // X1: the full hold (lib/full-hold.ts). Both switches default OFF; the registry is read only while one is on.
-  fullHold: () => fullHoldSwitches(process.env),
+  // X1: the full hold (lib/full-hold.ts). Approvals default OFF. 7.0.34: questions default ON, pending per request
+  // (a long stamp from a reinstalled hook); `COS_QUESTION_FULL_HOLD` wins, then the Settings row's file.
+  fullHold: () => fullHoldSwitches(process.env, readQuestionHoldSetting()),
   engineFor: (sessionId, ppid) => engineForHookProcess(sessionId, ppid),
   // X1 round 3: the asking engine's own status, read each tick for full-hold items only.
   engineStatus: (sessionId, pid) => registryStatusForPid(pid, sessionId),

package/server/lib/api-auth.ts

@@ -134,8 +134,9 @@ export function requireApiToken(apiToken: string, options: RequireApiTokenOption
       error: 'unauthorized',
       // Stable on purpose: clients key off this value, not the message.
       reason: 'pairing_token_rejected',
-      // Older COS Glasses builds, which cannot scan, show this message word for word.
-      message: 'Paste the pairing token from COS Control, or scan its code with COS Glasses 6.10.621 or newer.',
+      // Older COS Glasses builds show this message word for word. 7.0.32 (Miles 11/13 06:34): the glasses pair by
+      // the typed code only, so it no longer says scan.
+      message: 'Paste the pairing token from COS Control, or update COS Glasses and type the pairing code COS Control shows.',
     })
   }
 }

package/server/lib/archive.ts

@@ -510,11 +510,11 @@ export function getArchiveChatMessages(
  *  (sessionId, timestamp) instead of bare timestamp (collision-prone). */
 export function getArchiveDayMessages(
   date: string,
-): Array<{ query: string; text: string; timestamp: number; chatIndex: number; sessionId: string; no?: number; globalMsgNum?: number; messageEra?: string; modelPreference?: string; origin?: 'routine' | 'task'; originId?: string; attachments?: MediaAttachmentRef[] }> {
+): Array<{ query: string; text: string; timestamp: number; queryTimestamp?: number; chatIndex: number; sessionId: string; no?: number; globalMsgNum?: number; messageEra?: string; modelPreference?: string; origin?: 'routine' | 'task'; originId?: string; attachments?: MediaAttachmentRef[] }> {
   const archive = loadArchive(date)
   if (!archive) return []
 
-  const messages: Array<{ query: string; text: string; timestamp: number; chatIndex: number; sessionId: string; no?: number; globalMsgNum?: number; messageEra?: string; modelPreference?: string; origin?: 'routine' | 'task'; originId?: string; attachments?: MediaAttachmentRef[] }> = []
+  const messages: Array<{ query: string; text: string; timestamp: number; queryTimestamp?: number; chatIndex: number; sessionId: string; no?: number; globalMsgNum?: number; messageEra?: string; modelPreference?: string; origin?: 'routine' | 'task'; originId?: string; attachments?: MediaAttachmentRef[] }> = []
   for (const chat of archive.chats) {
     for (let i = 0; i < chat.exchanges.length; i++) {
       const ex = chat.exchanges[i]
@@ -531,6 +531,8 @@ export function getArchiveDayMessages(
             query: ex.content,
             text: next.content,
             timestamp: next.timestamp,
+            // 7.0.33 A2: the question's own time, as in the live view (routes/sessions.ts).
+            ...(Number.isFinite(ex.timestamp) ? { queryTimestamp: ex.timestamp } : {}),
             chatIndex: chat.id,
             sessionId: chat.sessionId,
             ...(globalMsgNum != null ? { no: globalMsgNum, globalMsgNum } : {}),

package/server/lib/claude-hooks-installer.ts

@@ -24,7 +24,8 @@ import { homedir } from 'node:os'
 import { dirname, join, resolve } from 'node:path'
 import { fileURLToPath } from 'node:url'
 import { atomicWriteFileSync } from './atomic-fs.js'
-import { FULL_HOLD_HOOK_WAIT_S, NON_QUESTION_MATCHER, QUESTION_MATCHER, fullHoldSwitches } from './full-hold.js'
+import { FULL_HOLD_HOOK_WAIT_S, FULL_HOLD_QUESTION_WAIT_PRIOR_S, FULL_HOLD_QUESTION_WAIT_S, NON_QUESTION_MATCHER, QUESTION_MATCHER, approvalFullHoldEnabled, defaultHoldTakesStamp, questionHoldMode, type QuestionHoldMode, type QuestionHoldSetting, type QuestionHoldSource } from './full-hold.js'
+import { questionHoldSettingPath, readQuestionHoldSetting } from './question-hold-setting.js'
 
 const __dirname = dirname(fileURLToPath(import.meta.url))
 
@@ -193,19 +194,68 @@ function priorWaitBlock(scriptPath: string, sub: HookSubscription, paths: HookPa
  * `COS_APPROVAL_FULL_HOLD` both off (the default) it is the ONE block every release since 6.60.0
  * writes, byte for byte (`split: false`). With either on it is TWO blocks of ours, split by matcher
  * (canary C9, both engines): `AskUserQuestion` waits `questionWaitS`, everything else `otherWaitS`;
- * a kind whose switch is on waits FULL_HOLD_HOOK_WAIT_S, the other keeps 630. Each block passes its
+ * a question whose switch is on waits FULL_HOLD_QUESTION_WAIT_S (8 h), an approval FULL_HOLD_HOOK_WAIT_S (1 h),
+ * and a kind whose switch is off keeps 630. Each block passes its
  * own wait to the script, so the stamp a request carries is its own block's. Reinstall hooks is what
  * writes it: until then the file reads `drift` (`priorWaitOnly`, still halt-ready).
  */
 export interface PermissionHookPlan { split: boolean; questionWaitS: number; otherWaitS: number }
 
-export function permissionHookPlan(env: NodeJS.ProcessEnv = process.env): PermissionHookPlan {
-  const on = fullHoldSwitches(env)
-  if (!on.questions && !on.approvals) return { split: false, questionWaitS: PERMISSION_HOOK_TIMEOUT_S, otherWaitS: PERMISSION_HOOK_TIMEOUT_S }
+/**
+ * X1, 7.0.34: under the DEFAULT question hold (`questionHoldMode` `default`) the plan depends on who asks.
+ *   - Reinstall hooks (`forInstall`): the split block with the 8 h question wait. That click is the opt-in.
+ *   - The status: the split plan only once the file already carries a question block longer than
+ *     DEFAULT_HOLD_MIN_STAMP_S (`installedQuestionWaitS`); before that, the one unsplit block, so a Mac that never
+ *     clicks reads `installed` with no banner and the 7.0.31 script stays current, exactly as 7.0.33.
+ * Explicit on and off (env or setting) are the same for both, as before.
+ */
+export interface PermissionHookPlanOptions {
+  /** The server-side setting; absent reads the file (`lib/question-hold-setting.ts`). */
+  setting?: QuestionHoldSetting | null
+  /** The AskUserQuestion block's timeout in the settings file now (status only). */
+  installedQuestionWaitS?: number | null
+  /** Reinstall hooks is asking: under the default, write the long question block. */
+  forInstall?: boolean
+}
+
+export function permissionHookPlan(env: NodeJS.ProcessEnv = process.env, options: PermissionHookPlanOptions = {}): PermissionHookPlan {
+  const setting = options.setting === undefined ? readQuestionHoldSetting() : options.setting
+  const mode = questionHoldMode(env, setting).mode
+  const questions = mode === 'on' || (mode === 'default' && (options.forInstall === true || defaultHoldTakesStamp(options.installedQuestionWaitS)))
+  const approvals = approvalFullHoldEnabled(env)
+  if (!questions && !approvals) return { split: false, questionWaitS: PERMISSION_HOOK_TIMEOUT_S, otherWaitS: PERMISSION_HOOK_TIMEOUT_S }
   return {
     split: true,
-    questionWaitS: on.questions ? FULL_HOLD_HOOK_WAIT_S : PERMISSION_HOOK_TIMEOUT_S,
-    otherWaitS: on.approvals ? FULL_HOLD_HOOK_WAIT_S : PERMISSION_HOOK_TIMEOUT_S,
+    // X1 (Miles 11/12 17:42): a held question waits 8 hours; approvals keep the 7.0.16 hour.
+    questionWaitS: questions ? FULL_HOLD_QUESTION_WAIT_S : PERMISSION_HOOK_TIMEOUT_S,
+    otherWaitS: approvals ? FULL_HOLD_HOOK_WAIT_S : PERMISSION_HOOK_TIMEOUT_S,
+  }
+}
+
+/**
+ * X1, 7.0.34: what `GET /api/session-hooks/status` adds as `sessionHooks.questionWait` (additive: `state` is
+ * untouched, so a Control that predates it shows exactly what it showed). `offered`: the default is on and this
+ * Mac's hooks do not carry the long question block yet, so Reinstall hooks would turn it on. `active`: the hooks
+ * carry it and the hold is not off, so a question from a session started since is held up to `waitS`.
+ */
+export interface QuestionWaitStatus {
+  mode: QuestionHoldMode
+  source: QuestionHoldSource
+  installedWaitS: number | null
+  waitS: number
+  active: boolean
+  offered: boolean
+}
+
+export function questionWaitStatus(env: NodeJS.ProcessEnv, setting: QuestionHoldSetting | null, installedQuestionWaitS: number | null): QuestionWaitStatus {
+  const { mode, source } = questionHoldMode(env, setting)
+  const long = defaultHoldTakesStamp(installedQuestionWaitS)
+  return {
+    mode, source,
+    installedWaitS: installedQuestionWaitS,
+    waitS: FULL_HOLD_QUESTION_WAIT_S,
+    active: mode !== 'off' && long,
+    offered: mode === 'default' && !long,
   }
 }
 
@@ -235,8 +285,10 @@ function priorWaitVariants(scriptPath: string, sub: HookSubscription, paths: Hoo
   if (!prior) return []
   const out: Record<string, unknown>[][] = [[prior]]
   if (plan.split) out.push([canonicalBlock(scriptPath, sub, paths)])
-  const waits = [PERMISSION_HOOK_TIMEOUT_S, FULL_HOLD_HOOK_WAIT_S]
-  for (const q of waits) for (const o of waits) {
+  // X1: the question block also had 3600 (7.0.16 to 7.0.31) before FULL_HOLD_QUESTION_WAIT_S.
+  const questionWaits = [PERMISSION_HOOK_TIMEOUT_S, FULL_HOLD_QUESTION_WAIT_PRIOR_S, FULL_HOLD_QUESTION_WAIT_S]
+  const otherWaits = [PERMISSION_HOOK_TIMEOUT_S, FULL_HOLD_HOOK_WAIT_S]
+  for (const q of questionWaits) for (const o of otherWaits) {
     if (plan.split && q === plan.questionWaitS && o === plan.otherWaitS) continue
     if (q === PERMISSION_HOOK_TIMEOUT_S && o === PERMISSION_HOOK_TIMEOUT_S) continue
     out.push(splitPermissionBlocks(scriptPath, sub, paths, q, o))
@@ -405,6 +457,8 @@ export interface HookStatus {
    */
   permissionHookTimeouts?: { question: number | null; approval: number | null }
   tokenPresent: boolean
+  /** X1, 7.0.34: the question hold for this Mac (`questionWaitStatus`); absent only when the settings could not be read. */
+  questionWait?: QuestionWaitStatus
 }
 
 function sha256File(path: string): string | null {
@@ -435,7 +489,7 @@ function hooksDisabled(settings: unknown): boolean {
   return !!settings && typeof settings === 'object' && (settings as { disableAllHooks?: unknown }).disableAllHooks === true
 }
 
-export function hookStatus(paths: { settingsPath?: string; scriptPath?: string; packageScriptPath?: string; hookPaths?: HookPaths; plan?: PermissionHookPlan } = {}): HookStatus {
+export function hookStatus(paths: { settingsPath?: string; scriptPath?: string; packageScriptPath?: string; hookPaths?: HookPaths; plan?: PermissionHookPlan; env?: NodeJS.ProcessEnv; setting?: QuestionHoldSetting | null } = {}): HookStatus {
   const settingsPath = paths.settingsPath ?? claudeSettingsPath()
   const scriptPath = paths.scriptPath ?? stableHookScriptPath()
   const packageScriptPath = paths.packageScriptPath ?? packagedHookScriptPath()
@@ -447,7 +501,13 @@ export function hookStatus(paths: { settingsPath?: string; scriptPath?: string;
   if (!read.ok) {
     return { state: read.reason, installed: false, settingsPath, scriptPath, scriptSha, packageScriptSha, subscribed: [], missing: HOOK_SUBSCRIPTIONS.map(s => s.event), drifted: [], priorWait: [], priorWaitOnly: false, permissionHookTimeoutS: null, tokenPresent }
   }
-  const events = subscribedEvents(read.settings, scriptPath, hookPaths, paths.plan ?? permissionHookPlan())
+  // X1, 7.0.34: the setting is read once per status; the plan then follows what the file already carries.
+  const env = paths.env ?? process.env
+  // The setting lives in the same COS home the hooks point at (production: ~/.cos-glasses; a test: its own box).
+  const setting = paths.setting === undefined ? readQuestionHoldSetting(questionHoldSettingPath(hookPaths.home)) : paths.setting
+  const installedQuestionWaitS = permissionHookTimeoutForToolS(read.settings, 'AskUserQuestion')
+  const plan = paths.plan ?? permissionHookPlan(env, { setting, installedQuestionWaitS })
+  const events = subscribedEvents(read.settings, scriptPath, hookPaths, plan)
   const permissionWaitS = permissionHookTimeoutS(read.settings)
   const permissionHookTimeouts = {
     question: permissionHookTimeoutForToolS(read.settings, 'AskUserQuestion'),
@@ -457,12 +517,12 @@ export function hookStatus(paths: { settingsPath?: string; scriptPath?: string;
   if (hooksDisabled(read.settings)) state = 'disabled_by_settings'
   else if (events.subscribed.length === 0 && events.drifted.length === 0) state = 'missing'
   else if (events.missing.length > 0 || events.drifted.length > 0) state = 'drift'
-  else if (!scriptSha || (packageScriptSha && scriptSha !== packageScriptSha)) state = 'script_outdated'
+  else if (!scriptCurrentForPlan(scriptSha, packageScriptSha, plan)) state = 'script_outdated'
   else state = 'installed'
   const priorWaitOnly = state === 'drift' && events.missing.length === 0 && events.drifted.length > 0
     && events.drifted.every(event => events.priorWait.includes(event))
   const observerOnlyDrift = state === 'drift' && events.missing.length > 0 && events.missing.every(event => event === 'PreCompact') && events.drifted.every(event => events.priorWait.includes(event))
-  return { observerOnlyDrift, state, installed: state === 'installed', settingsPath, scriptPath, scriptSha, packageScriptSha, ...events, priorWaitOnly, permissionHookTimeoutS: permissionWaitS, ...(paths.plan?.split || permissionHookPlan().split || permissionHookTimeouts.question !== permissionHookTimeouts.approval ? { permissionHookTimeouts } : {}), tokenPresent }
+  return { observerOnlyDrift, state, installed: state === 'installed', settingsPath, scriptPath, scriptSha, packageScriptSha, ...events, priorWaitOnly, permissionHookTimeoutS: permissionWaitS, ...(plan.split || permissionHookTimeouts.question !== permissionHookTimeouts.approval ? { permissionHookTimeouts } : {}), tokenPresent, questionWait: questionWaitStatus(env, setting, installedQuestionWaitS) }
 }
 
 /**
@@ -493,8 +553,31 @@ export const HALT_CAPABLE_PRIOR_SCRIPT_SHAS: readonly string[] = [
   '0e1bbb9816c9475436f89f6326d5504eccc9aa6519ff5e466b949d53a73d8439',
   '1877c90c5359571dfc74c6d03395104a73925868147e8a50cd9d7b4226b1b5ca',
   '0fd4f98801333399625701bdc83ed1a5906bbf18c449d0586daa6b8e58ada7f3',
+  // X1: the 6.71.7 to 7.0.31 script (WAIT_CAP_ONLY_PRIOR_SCRIPT_SHAS below); its halt check is this package's.
+  'ee32d7a6b051cc1b9250c0b732fbfe528a59b4930daaf27696830d5803d6687a',
 ]
 
+/**
+ * X1 (8 h question wait): the script 6.71.7 through 7.0.31 shipped. It differs from this package's in ONE line,
+ * the longest PermissionRequest wait it accepts (3600 then, FULL_HOLD_QUESTION_WAIT_S now), and only a question
+ * block written with the full hold on ever passes more than 3600. So while the plan does not ask for a longer
+ * question wait it does everything this package's script does, and is reported current: no Reinstall banner,
+ * Cursor and Codex desk cancel unchanged. A Mac that never turns COS_QUESTION_FULL_HOLD on sees no change. With
+ * the switch on it reads `script_outdated` until Reinstall hooks copies this package's script (which that switch
+ * needs anyway for the split block). Pinned against `__fixtures__/cos-session-hook-7.0.31` by a test that diffs
+ * it with this package's script line by line.
+ */
+export const WAIT_CAP_ONLY_PRIOR_SCRIPT_SHAS: readonly string[] = [
+  'ee32d7a6b051cc1b9250c0b732fbfe528a59b4930daaf27696830d5803d6687a',
+]
+
+/** Whether the installed script is current for this plan (see WAIT_CAP_ONLY_PRIOR_SCRIPT_SHAS). */
+export function scriptCurrentForPlan(scriptSha: string | null, packageScriptSha: string | null, plan: Pick<PermissionHookPlan, 'questionWaitS'>): boolean {
+  if (!scriptSha) return false
+  if (!packageScriptSha || scriptSha === packageScriptSha) return true
+  return plan.questionWaitS <= FULL_HOLD_QUESTION_WAIT_PRIOR_S && WAIT_CAP_ONLY_PRIOR_SCRIPT_SHAS.includes(scriptSha)
+}
+
 /**
  * 6.53.3: can the hooks on this Mac stop a desk Claude run now? `installed`, or the only
  * difference is a halt-capable earlier script (above). What the cancel route's
@@ -523,7 +606,9 @@ export function hookHaltReady(status: Pick<HookStatus, 'installed' | 'state' | '
  * the wrong run. Claude's own readiness (`hookHaltReady`) is unchanged.
  */
 export function cursorDeskHaltReady(status: Parameters<typeof hookHaltReady>[0]): boolean {
-  return hookHaltReady(status) && typeof status.scriptSha === 'string' && status.scriptSha === status.packageScriptSha
+  if (!hookHaltReady(status) || typeof status.scriptSha !== 'string') return false
+  // X1: the 7.0.31 script reads Cursor's payload exactly as this package's does (they differ only in the wait cap).
+  return status.scriptSha === status.packageScriptSha || WAIT_CAP_ONLY_PRIOR_SCRIPT_SHAS.includes(status.scriptSha)
 }
 
 const INSTALL_COMMAND = 'npx --yes @gotcos/glasses-server@latest --hooks install'
@@ -646,7 +731,8 @@ export function installClaudeHooks(options: InstallOptions = {}): InstallResult
   const packageScriptPath = options.packageScriptPath ?? packagedHookScriptPath()
   const hookPaths = options.hookPaths ?? currentHookPaths()
   const read = readSettings(settingsPath)
-  const plan = options.plan ?? permissionHookPlan()
+  // X1, 7.0.34: Reinstall hooks is the opt-in, so under the default it writes the long question block.
+  const plan = options.plan ?? permissionHookPlan(process.env, { forInstall: true, setting: readQuestionHoldSetting(questionHoldSettingPath(hookPaths.home)) })
   const statusNow = () => hookStatus({ settingsPath, scriptPath, packageScriptPath, hookPaths, plan })
   const refuse = (reason: string, scriptCopied = false): InstallResult => ({ ok: false, reason, changed: false, scriptCopied, backupPath: null, status: statusNow() })
   if (!read.ok) return refuse(read.reason)

package/server/lib/codex-hooks-installer.ts

@@ -40,6 +40,7 @@ import { dirname, join, resolve } from 'node:path'
 import { atomicWriteFileSync } from './atomic-fs.js'
 import {
   PERMISSION_HOOK_TIMEOUT_S,
+  WAIT_CAP_ONLY_PRIOR_SCRIPT_SHAS,
   backupSettings,
   currentHookPaths,
   ensureStableHookScript,
@@ -264,7 +265,9 @@ export function codexHookStatus(paths: CodexHookPaths = {}): CodexHookStatus {
   const hookPaths = paths.hookPaths ?? currentHookPaths()
   const scriptSha = sha256File(scriptPath)
   const packageScriptSha = sha256File(packageScriptPath)
-  const scriptOk = scriptSha !== null && scriptSha === packageScriptSha
+  // X1: the 7.0.31 script differs from this package's only in the longest question wait it accepts, which Codex never
+  // uses (it has no question block), so it stays current for Codex (WAIT_CAP_ONLY_PRIOR_SCRIPT_SHAS).
+  const scriptOk = scriptSha !== null && (scriptSha === packageScriptSha || WAIT_CAP_ONLY_PRIOR_SCRIPT_SHAS.includes(scriptSha))
   const read = readHooksFile(hooksPath)
   if (!read.ok) {
     return { state: read.reason, installed: false, hooksPath, scriptPath, scriptSha, packageScriptSha, scriptOk, subscribed: [], missing: CODEX_HOOK_SUBSCRIPTIONS.map(s => s.event), drifted: [], duplicated: [] }