@melaya/runner 1.1.24 → 1.1.26

package/dist/assistantHost.py

@@ -719,12 +719,20 @@ def _build_agent():
         max_iters=(int(os.environ.get("MEL_ASSISTANT_MAX_ITERS_PHONE", "300") or "300") if phone_enabled
                    else (int(os.environ.get("MEL_ASSISTANT_MAX_ITERS_BROWSER", "300") or "300") if browser_enabled
                          else (40 if connector_services else 8))),
-        # Driving a device IS the long-horizon shape: read the screen, do one
-        # thing, read again. Without this the codex latency cap silently cut the
-        # 300 above to 3 — one click and a look — and every codex browser turn
-        # ended mid-task claiming an "iteration limit". Connector and plain
-        # chat turns keep the cap: they are not act-and-observe.
-        long_horizon=bool(phone_enabled or browser_enabled),
+        # EVERY assistant turn is long-horizon, not only device-driving ones.
+        #
+        # The codex cap is a latency default written for pipeline phases. An
+        # assistant turn is interactive - a human is waiting - and its shape is
+        # always read, do one thing, read again. A connector turn alone needs
+        # search_tools + activate_tool + the call + a synthesis round: already
+        # four, so a cap of three truncates before the model can answer.
+        #
+        # This was briefly gated on (phone or browser). That passed testing only
+        # because the tester's runner advertises browser capability, and
+        # _browser_capable() is CAPABILITY presence rather than turn usage - so
+        # it was true for all of their turns. A user whose runner is not
+        # browser-capable would still have been clamped to 3 on ordinary chat.
+        long_horizon=True,
         reliability=True,
         bounded_memory=True,
     )

package/dist/browserGrantVerify.js

@@ -143,10 +143,16 @@ export function loadPinnedPublicKeysFromEnv() {
 // Verifier
 // ---------------------------------------------------------------------
 export const DEFAULT_CLOCK_TOLERANCE_SECONDS = 30;
-/** Sanity ceiling: matches the server's MAX_TTL_SECONDS. A "valid"
- *  token claiming a longer life than the issuer can mint is forged or
- *  corrupt, so it is rejected regardless of signature. */
-const MAX_LIFETIME_SECONDS = 900;
+/** Sanity ceiling: MUST match the server's MAX_TTL_SECONDS
+ *  (server/src/services/browser/browserGrant.ts). A "valid" token claiming a
+ *  longer life than the issuer can mint is forged or corrupt, so it is
+ *  rejected regardless of signature.
+ *
+ *  Raised 900s -> 4h alongside the server. Because this half ships in the
+ *  runner, a server deployed ahead of a runner republish would mint grants
+ *  this rejects with claims_invalid — publish the runner before, or at the
+ *  same time as, the server change. */
+const MAX_LIFETIME_SECONDS = 4 * 60 * 60;
 function b64urlJson(part, what) {
     let buf;
     try {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@melaya/runner",
-  "version": "1.1.24",
+  "version": "1.1.26",
   "description": "Run Melaya AI pipelines locally with your own LM Studio or Ollama models",
   "license": "UNLICENSED",
   "private": false,