@indigoai-us/hq-cli 5.243.0 → 5.244.0

package/CHANGELOG.md

@@ -2,6 +2,17 @@
 
 ## [Unreleased]
 
+## [5.244.0] — 2026-09-27
+
+### Changed
+
+- The setup bot no longer posts "This one takes a minute. I'll reply here as
+  soon as it's done." when a step runs long. Other bots keep their notice.
+- After the bundled setup bot connects its first app, it says "Great, <Tool> is
+  connected" with a link to the company's integrations page on hq.computer.
+- The bundled setup bot invites teammates through the new-hire flow when HQ
+  has it, and tells the person to have the invitee check their spam folder.
+
 ## [5.243.0] — 2026-09-27
 ### Added
 
@@ -1630,6 +1641,18 @@
 
 ## [Unreleased]
 
+### Fixed
+
+- A bot whose agent home is on a network share can now mint a token. The
+  refresh lock was a POSIX hard-link lock, and CIFS/SMB shares — Azure Files
+  again — do not implement `link()` at all, so every mint failed with
+  ENOTSUP and took the whole probe down with it: no heartbeat ever posted
+  and the inbox poller retried and failed every 15 seconds. The lock now
+  falls back to an exclusive create, which gives the same guarantee and
+  works there. Contention still surfaces as EEXIST on both paths, so
+  stale-owner reclamation is unchanged, and a link that fails for any other
+  reason is still a real error.
+
 - `hq mesh daemon install` and `hq mesh daemon run` unload and remove the
   legacy `ai.getindigo.hq-work-mesh-listen` unit (LaunchAgent, systemd user
   unit, or Scheduled Task) so only the daemon subscribes. The daemon writes

package/assets/bot-workers/setup/skills/agents-and-team.md

@@ -114,16 +114,29 @@ console, and they sign in in the browser.
 
 ## Inviting a teammate
 
+Every invite runs through HQ's new-hire flow. Read
+`.claude/skills/new-hire/SKILL.md` in the HQ folder before the first invite and
+follow its steps: check `hq members list` first, set the role, invite, then
+the access that person needs (groups, shared apps and keys) and the
+acceptance follow-through. It is your playbook, not something to show them:
+ask its questions in plain words, one at a time, skip what setup has not
+created yet (groups, an onboarding packet), and never name the skill or its
+command. If that file is not in this HQ, the steps below are enough.
+
 1. Ask for one email and whether they should be a member or an admin
-   (member is the default; admins can only invite members).
+   (member is the default; admins can only invite members). If they already
+   said who, do not ask again.
 2. Confirm in one line that an invitation email will go to that address, and
    wait for yes.
-3. Run `hq members invite <email> --company <slug> --role member`.
+3. Send the invite the way the new-hire flow says
+   (`hq members invite <email> --company <slug> --role member`).
 4. Tell them what happens next: the teammate opens the email, signs in with
    Google or Microsoft, and gets the company in their own HQ, so their Claude
    Code or Codex knows the business from their first session. Say what they
-   will see that matters to this person (the connected calls, the client
-   homes).
+   will see that matters to this person (the client homes, and any app you
+   have shared with them; a connected app stays private to the person who
+   connected it until it is shared). Always add: "Tell them to check their
+   spam folder if the email doesn't show up in a few minutes."
 5. Check with `hq members list` (pending until they accept). If they never
    got it, `--resend` sends it again.
 

package/assets/bot-workers/setup/skills/your-business.md

@@ -142,6 +142,17 @@ the way a good engineer would, and then do it:
    what it means for their team (see "What HQ is" in your instructions). A
    connection is not done until this read works. Never say "connected",
    "done" or "everything is set up" before it does.
+6. **After the first connection only, say where connections live.** Once
+   the read works for the first app they connect, open your reply with the
+   confirmation and the link, in these words:
+   "Great, <Tool> is connected. You can see everything that's connected at
+   https://hq.computer/companies/<company-slug>/integrations, or ask me or
+   any other AI in HQ to connect another." Use the company's slug from the
+   Owner context (for a personal connection, the link is
+   https://hq.computer/personal/integrations). Then the real data from step
+   5 and the next question. Say this once in the whole setup. For every
+   later connection, skip it: show the real data from step 5 and move on.
+   Give the link again only if they ask where connections live.
 
 If a step needs something only they can do (an admin approval, a paid plan),
 say exactly what, record it in the progress note as waiting, and move on to

package/dist/lib/bot/progress.d.ts

@@ -27,9 +27,6 @@ export declare const PROGRESS_COALESCE_MS = 2000;
 export declare const PROGRESS_MIN_GAP_MS = 4000;
 export declare const WORKING_NOTICE_MS = 60000;
 export declare const WORKING_NOTICE_TEXT = "Working on it \u2014 I'll reply here when it's done.";
-/** The setup bot's heads-up, sent once when a turn runs past SETUP_WORKING_NOTICE_MS. */
-export declare const SETUP_WORKING_NOTICE_MS = 30000;
-export declare const SETUP_WORKING_NOTICE_TEXT = "This one takes a minute. I'll reply here as soon as it's done.";
 export interface ProgressPosterOptions {
     /** Post one message; resolve true when it was delivered. */
     send: (body: string) => Promise<boolean>;

package/dist/lib/bot/progress.js

@@ -27,9 +27,6 @@ export const PROGRESS_COALESCE_MS = 2_000;
 export const PROGRESS_MIN_GAP_MS = 4_000;
 export const WORKING_NOTICE_MS = 60_000;
 export const WORKING_NOTICE_TEXT = "Working on it — I'll reply here when it's done.";
-/** The setup bot's heads-up, sent once when a turn runs past SETUP_WORKING_NOTICE_MS. */
-export const SETUP_WORKING_NOTICE_MS = 30_000;
-export const SETUP_WORKING_NOTICE_TEXT = "This one takes a minute. I'll reply here as soon as it's done.";
 /** Whitespace-insensitive form used to recognise repeated text. */
 export function normalizeForCompare(text) {
     return text.replace(/\s+/g, "");

package/dist/lib/bot/run.js

@@ -57,7 +57,7 @@ import { ensureBotSessionMeta } from "./company-bind.js";
 import { readBotCredsIdentity } from "./creds.js";
 import { isProcessed, markProcessed, readInboxState } from "./inbox-state.js";
 import { clearInflight, patchInflight, readInflight, readInflightTurns, writeInflight } from "./inflight.js";
-import { containsNoReplySentinel, ProgressPoster, SETUP_WORKING_NOTICE_MS, SETUP_WORKING_NOTICE_TEXT, } from "./progress.js";
+import { containsNoReplySentinel, ProgressPoster, } from "./progress.js";
 import { splitBody } from "./split.js";
 import { createBotLogger } from "./log.js";
 import { buildSystemPrompt, introDmText, readPromptSources } from "./prompt.js";
@@ -737,12 +737,11 @@ export async function runBot(deps) {
         };
         const poster = new ProgressPoster({
             // The setup bot talks to someone new to HQ: its notes to itself never
-            // reach them, and a long step gets a heads-up instead of silence.
-            ...(isSetupBot
-                ? { dropPreToolMessages: true, workingNoticeMs: SETUP_WORKING_NOTICE_MS, workingNoticeText: SETUP_WORKING_NOTICE_TEXT }
-                : {}),
+            // reach them, and it posts no "still working" notice either — the
+            // desktop app shows that the bot is working.
+            ...(isSetupBot ? { dropPreToolMessages: true } : {}),
             ...deps.progress,
-            ...(args.workingNotice === false || silenceable ? { workingNoticeMs: 0 } : {}),
+            ...(args.workingNotice === false || silenceable || isSetupBot ? { workingNoticeMs: 0 } : {}),
             ...(silenceable ? { buffer: true } : {}),
             send: makeSendFn(args.send),
             ...(args.sendFinal ? { sendFinal: makeSendFn(args.sendFinal) } : {}),
@@ -1458,7 +1457,6 @@ export async function runBot(deps) {
             tReceived,
             send,
             sendFinal,
-            // The setup bot's own notice (SETUP_WORKING_NOTICE_TEXT) is set where the poster is built.
             silenceable: target.kind === "room" && !target.mentioned,
             ...(readDirs.length ? { readDirs } : {}),
             ...(target.kind === "room"

package/dist/utils/cognito-session.js

@@ -29,6 +29,7 @@ import { loadCachedTokens, isExpiring, refreshTokens, saveCachedTokens, browserL
 import { CLI_NAME, CLI_VERSION } from "../cli-version.js";
 import { daemonDir } from "../lib/mesh/live/daemon/paths.js";
 import { workMeshRoot } from "../lib/mesh/live/paths.js";
+import { acquireLockFileExclusively } from "./exclusive-lock.js";
 // Re-export the cached-session primitives for callers that must deliberately
 // avoid the refresh/login behavior in the higher-level helpers below.
 export { isExpiring, isMachineIdentity, loadCachedTokens };
@@ -557,7 +558,7 @@ async function withAbortablePersonRefreshLock(signal, fn) {
         for (;;) {
             throwIfAborted(signal);
             try {
-                fs.linkSync(candidate, lockFile);
+                acquireLockFileExclusively(candidate, lockFile, stateDir);
                 held = true;
                 break;
             }

package/dist/utils/exclusive-lock.d.ts

@@ -0,0 +1,32 @@
+/**
+ * Acquiring a lock file on a filesystem that may not do hard links.
+ *
+ * The refresh lock is a classic POSIX `link()` lock: write a candidate file,
+ * hard-link it into place, and let EEXIST mean somebody else holds it. That
+ * is atomic on a local disk and on NFS, and it is simply absent on CIFS/SMB
+ * — Azure Files returns ENOTSUP for `link()` on every call, so a bot whose
+ * agent home lives on such a share could never mint a token at all. Its
+ * probe failed every line with:
+ *
+ *     ENOTSUP: operation not supported on socket, link
+ *       '.../cognito-tokens.json.lock.candidate.48560...' -> '.../lock'
+ *
+ * An exclusive create (`open(..., O_EXCL)`) gives the same guarantee — the
+ * server refuses the second creator — and works on those shares. So the link
+ * is tried first, and a filesystem that says it cannot do links is remembered
+ * and switched to the exclusive-create path for the rest of the process.
+ *
+ * Both paths fail with EEXIST when the lock is held, so contention, stale-
+ * owner reclamation and release are unchanged for every caller.
+ */
+/** Test seam: forget what we learned about which filesystems do links. */
+export declare function resetLinkSupportCache(): void;
+/**
+ * Create `lockFile` exclusively, or throw EEXIST if it already exists.
+ *
+ * `candidate` is an already-written file holding the owner's pid; on a
+ * link-capable filesystem it becomes the lock, and otherwise its contents
+ * are written directly. Either way the lock ends up holding the same bytes.
+ */
+export declare function acquireLockFileExclusively(candidate: string, lockFile: string, dirKey: string): void;
+//# sourceMappingURL=exclusive-lock.d.ts.map

package/dist/utils/exclusive-lock.js

@@ -0,0 +1,75 @@
+/**
+ * Acquiring a lock file on a filesystem that may not do hard links.
+ *
+ * The refresh lock is a classic POSIX `link()` lock: write a candidate file,
+ * hard-link it into place, and let EEXIST mean somebody else holds it. That
+ * is atomic on a local disk and on NFS, and it is simply absent on CIFS/SMB
+ * — Azure Files returns ENOTSUP for `link()` on every call, so a bot whose
+ * agent home lives on such a share could never mint a token at all. Its
+ * probe failed every line with:
+ *
+ *     ENOTSUP: operation not supported on socket, link
+ *       '.../cognito-tokens.json.lock.candidate.48560...' -> '.../lock'
+ *
+ * An exclusive create (`open(..., O_EXCL)`) gives the same guarantee — the
+ * server refuses the second creator — and works on those shares. So the link
+ * is tried first, and a filesystem that says it cannot do links is remembered
+ * and switched to the exclusive-create path for the rest of the process.
+ *
+ * Both paths fail with EEXIST when the lock is held, so contention, stale-
+ * owner reclamation and release are unchanged for every caller.
+ */
+import * as fs from "fs";
+/**
+ * `link()` errnos that mean "this filesystem does not implement links"
+ * rather than "the link failed". EEXIST is deliberately NOT here: that is
+ * ordinary contention and the caller's own retry loop owns it.
+ */
+const LINK_UNSUPPORTED_CODES = new Set([
+    "ENOTSUP",
+    "EOPNOTSUPP",
+    "EPERM",
+    "EXDEV",
+    "EACCES",
+]);
+/**
+ * Per-process, per-directory memory of a filesystem that cannot hard-link,
+ * so the cost is one failed call rather than one per acquisition.
+ */
+const linkUnsupportedDirs = new Set();
+/** Test seam: forget what we learned about which filesystems do links. */
+export function resetLinkSupportCache() {
+    linkUnsupportedDirs.clear();
+}
+/**
+ * Create `lockFile` exclusively, or throw EEXIST if it already exists.
+ *
+ * `candidate` is an already-written file holding the owner's pid; on a
+ * link-capable filesystem it becomes the lock, and otherwise its contents
+ * are written directly. Either way the lock ends up holding the same bytes.
+ */
+export function acquireLockFileExclusively(candidate, lockFile, dirKey) {
+    if (!linkUnsupportedDirs.has(dirKey)) {
+        try {
+            fs.linkSync(candidate, lockFile);
+            return;
+        }
+        catch (error) {
+            const code = error.code ?? "";
+            // Contention is the caller's business, and an unrecognised failure is
+            // a real fault: neither one means "try the other strategy".
+            if (code === "EEXIST")
+                throw error;
+            if (!LINK_UNSUPPORTED_CODES.has(code))
+                throw error;
+            linkUnsupportedDirs.add(dirKey);
+        }
+    }
+    // O_EXCL: the create fails with EEXIST if anyone got there first, which is
+    // exactly the signal the link path produced.
+    fs.writeFileSync(lockFile, fs.readFileSync(candidate), {
+        flag: "wx",
+        mode: 0o600,
+    });
+}
+//# sourceMappingURL=exclusive-lock.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@indigoai-us/hq-cli",
-  "version": "5.243.0",
+  "version": "5.244.0",
   "description": "HQ by Indigo management CLI — modules and cloud sync",
   "main": "dist/index.js",
   "bin": {