chore: sync upstream main 7ab92d7622ec

.dockerignore

@@ -35,10 +35,14 @@ coverage
 /docs/
 *.md
 
-# Only the web workspace is used by Dockerfile.web. Default-exclude future
-# app workspaces so they do not silently enter the build context.
+# Dockerfile.web needs the web workspace and root dependency patch inputs.
+# Default-exclude other app files so they do not enter the build context.
 /apps/*
 !/apps/web/
+!/apps/mobile
+/apps/mobile/*
+!/apps/mobile/patches
+!/apps/mobile/patches/**
 
 # Repository-only tooling
 /.github/

.github/RELEASING.md

@@ -10,6 +10,14 @@ formulae, and container images.
 The verification job runs the Go tests and `govulncheck` before any publishing
 job starts. The vulnerability scan is fail-closed by default.
 
+CI and release jobs require Go `~1.26.9`: at least 1.26.9, while accepting
+newer 1.26 patches. This security floor is independent of the development
+minimum in `server/go.mod`. A plain `1.26.x` can resolve to an older patch
+while the `setup-go` version manifest catches up with an official Go release.
+When raising the security floor, update all Go workflows and the pinned
+Go builder image in `Dockerfile` together so shipped binaries also receive
+the fixes.
+
 ## Emergency vulnerability-scan bypass
 
 Use the bypass only when `govulncheck` itself or its live vulnerability database

.github/workflows/ci.yml

@@ -72,7 +72,7 @@ jobs:
       - name: Setup Go
         uses: actions/setup-go@v5
         with:
-          go-version: "1.26.x"
+          go-version: "~1.26.9"
           check-latest: true
           cache-dependency-path: server/go.sum
 
@@ -348,9 +348,9 @@ jobs:
         id: go
         uses: actions/setup-go@v5
         with:
-          # Deliberately independent from the minimum patch in server/go.mod:
-          # CI follows the newest 1.26 patch available to setup-go.
-          go-version: "1.26.x"
+          # Keep the security floor even when the setup-go manifest lags;
+          # continue accepting newer patches within Go 1.26.
+          go-version: "~1.26.9"
           check-latest: true
           cache: false
 
@@ -450,7 +450,7 @@ jobs:
         id: go
         uses: actions/setup-go@v5
         with:
-          go-version: "1.26.x"
+          go-version: "~1.26.9"
           check-latest: true
           cache: false
 
@@ -488,9 +488,9 @@ jobs:
       - name: Setup Go
         uses: actions/setup-go@v5
         with:
-          # Deliberately independent from the minimum patch in server/go.mod:
-          # CI follows the newest 1.26 patch available to setup-go.
-          go-version: "1.26.x"
+          # Keep the security floor even when the setup-go manifest lags;
+          # continue accepting newer patches within Go 1.26.
+          go-version: "~1.26.9"
           check-latest: true
           cache-dependency-path: server/go.sum
 
@@ -527,9 +527,9 @@ jobs:
       - name: Setup Go
         uses: actions/setup-go@v5
         with:
-          # Deliberately independent from the minimum patch in server/go.mod:
-          # CI follows the newest 1.26 patch available to setup-go.
-          go-version: "1.26.x"
+          # Keep the security floor even when the setup-go manifest lags;
+          # continue accepting newer patches within Go 1.26.
+          go-version: "~1.26.9"
           check-latest: true
           cache-dependency-path: server/go.sum
 
@@ -547,6 +547,13 @@ jobs:
         # real skills instead of the test directories.
         run: go test ./internal/daemon -v -run '^(TestListRuntimeLocalSkills_HermesFollowsTaskHome|TestLocalSkills_DiscoversACPProviderRoots)$' -count=1 -timeout=5m
 
+      - name: Test Windows Git Bash temp lifecycle
+        working-directory: server
+        run: |
+          $env:MULTICA_TEST_GIT_BASH = "$env:ProgramFiles\Git\usr\bin\bash.exe"
+          if (-not (Test-Path -LiteralPath $env:MULTICA_TEST_GIT_BASH)) { throw "Git for Windows is required" }
+          go test -tags=gitbashintegration ./internal/daemon -v -run '^(TestWindowsGitBashTaskTempLifecycle|TestTaskMulticaEnvironment.*|TestTaskTempBaseDir)$' -count=1 -timeout=5m
+
       - name: Test Windows agent launcher argv/stdin handling
         working-directory: server
         # Agent prompts must never reach a Windows launcher through argv: the
@@ -788,7 +795,7 @@ jobs:
       - uses: actions/checkout@v6
       - uses: actions/setup-go@v5
         with:
-          go-version: "1.26.x"
+          go-version: "~1.26.9"
           cache-dependency-path: server/go.sum
       - name: Verify Cursor background lifecycle and watchdog races
         shell: bash

.github/workflows/desktop-smoke.yml

@@ -30,9 +30,9 @@ jobs:
       - name: Setup Go
         uses: actions/setup-go@v5
         with:
-          # Deliberately independent from the minimum patch in server/go.mod:
-          # CI follows the newest 1.26 patch available to setup-go.
-          go-version: "1.26.x"
+          # Keep the security floor even when the setup-go manifest lags;
+          # continue accepting newer patches within Go 1.26.
+          go-version: "~1.26.9"
           check-latest: true
           cache-dependency-path: server/go.sum
 

.github/workflows/openclaw-config-smoke.yml

@@ -35,7 +35,7 @@ jobs:
       - name: Setup Go
         uses: actions/setup-go@v5
         with:
-          go-version: "1.26.x"
+          go-version: "~1.26.9"
           check-latest: true
           cache-dependency-path: server/go.sum
 

.github/workflows/release.yml

@@ -54,9 +54,9 @@ jobs:
       - name: Setup Go
         uses: actions/setup-go@v5
         with:
-          # Deliberately independent from the minimum patch in server/go.mod:
-          # releases follow the newest 1.26 patch available to setup-go.
-          go-version: "1.26.x"
+          # Keep the security floor even when the setup-go manifest lags;
+          # continue accepting newer patches within Go 1.26.
+          go-version: "~1.26.9"
           check-latest: true
           cache-dependency-path: server/go.sum
 
@@ -98,9 +98,9 @@ jobs:
       - name: Setup Go
         uses: actions/setup-go@v5
         with:
-          # Deliberately independent from the minimum patch in server/go.mod:
-          # releases follow the newest 1.26 patch available to setup-go.
-          go-version: "1.26.x"
+          # Keep the security floor even when the setup-go manifest lags;
+          # continue accepting newer patches within Go 1.26.
+          go-version: "~1.26.9"
           check-latest: true
           cache-dependency-path: server/go.sum
 
@@ -424,9 +424,9 @@ jobs:
       - name: Setup Go
         uses: actions/setup-go@v5
         with:
-          # Deliberately independent from the minimum patch in server/go.mod:
-          # releases follow the newest 1.26 patch available to setup-go.
-          go-version: "1.26.x"
+          # Keep the security floor even when the setup-go manifest lags;
+          # continue accepting newer patches within Go 1.26.
+          go-version: "~1.26.9"
           check-latest: true
           cache-dependency-path: server/go.sum
 

.goreleaser.yml

@@ -17,6 +17,7 @@ builds:
       - -s -w
       - -X main.version={{.Version}}
       - -X main.commit={{.ShortCommit}}
+      - -X main.buildCommit={{.FullCommit}}
       - -X main.date={{.Date}}
     env:
       - CGO_ENABLED=0

.vercelignore

@@ -36,6 +36,11 @@ _features
 !/apps/web/**
 !/apps/docs
 !/apps/docs/**
+# Root pnpm patchedDependencies needs these files even for frontend-only installs.
+!/apps/mobile
+/apps/mobile/*
+!/apps/mobile/patches
+!/apps/mobile/patches/**
 /scripts/
 
 *.log

CLI_AND_DAEMON.md

@@ -169,6 +169,57 @@ availability stays independent of a third party's release cadence.
 Desktop-managed daemons ignore both, because the Desktop app owns its bundled
 CLI's lifecycle.
 
+### Boot autostart
+
+Opt-in: only `multica daemon autostart enable` registers the profile's
+daemon with the OS, so the machine brings it back after a reboot or re-login
+— without that, every reboot takes the runtime offline and queued runs sit
+unclaimed. `daemon start` never registers on its own: it prints a one-line
+hint when nothing is registered, and otherwise stays out of the way.
+
+| Platform | Mechanism | Where |
+| --- | --- | --- |
+| Windows | Per-user Run key | `HKCU\Software\Microsoft\Windows\CurrentVersion\Run`, value `Multica` |
+| macOS | launchd LaunchAgent | `~/Library/LaunchAgents/ai.multica.daemon.plist` (runs at login) |
+| Linux | systemd user unit | `~/.config/systemd/user/multica-daemon.service`; without systemd, an XDG autostart entry under `~/.config/autostart/` |
+
+Each entry runs `multica daemon start --foreground` for that profile — named
+profiles get their own entry, so several daemons on one machine never collide.
+Daemon settings are read from the profile's config (`multica config set ...`)
+at start. Shell environment variables do **not** travel into a login session:
+only `PATH` is snapshotted at registration (and refreshed while Multica owns
+the entry), which is what keeps agent CLIs installed via Homebrew, nvm, or a
+user bin directory discoverable — persist everything else with
+`multica config set` or your user environment. On Linux, `enable` also tells
+you (it does not run it for you) how to `loginctl enable-linger $USER` so a
+headless machine starts the unit at boot rather than at first login.
+
+```bash
+multica daemon autostart enable         # the only thing that registers
+multica daemon autostart status         # what is registered, and where
+multica daemon autostart status --output json
+multica daemon autostart disable        # remove the registration
+```
+
+Refresh: while an entry exists and carries Multica's ownership marker,
+`daemon start` silently rewrites it so a moved executable (a Homebrew
+upgrade, a self-update) heals. An entry at the same path that Multica did
+not create — your own systemd unit, a hand-written LaunchAgent — is never
+refreshed and never overwritten: `enable`/`disable` refuse it and say which
+file is in the way, and the refresh is additionally skipped when the daemon
+was launched by an external supervisor (systemd `INVOCATION_ID` for a unit
+that is not ours).
+
+`daemon stop` stops the daemon but keeps the registration — it says nothing
+about the next boot; `autostart disable` is what turns that off. Disabling
+never disturbs a running daemon: on Linux the wants link is removed while
+the managed unit file stays (unlinked), so the current session keeps the
+unit's restart policy across a binary update and only the next-login start
+goes away; on macOS the plist is deleted without a `launchctl bootout`, so
+the process launchd is supervising keeps running. Daemons started by the
+Multica Desktop app are never registered or refreshed here: the app owns
+that daemon's lifecycle through its own app-start daemon preference.
+
 ### Stop
 
 ```bash
@@ -309,7 +360,7 @@ The daemon periodically scans `MULTICA_WORKSPACES_ROOT` and applies several disk
 
 - **Hermes session store reclamation** — a conversation's Hermes transcript (`state.db`) lives at `<profile dir>/hermes-sessions/<agent-id>/<hermes-profile>/<conversation>/`, outside any task directory, so a follow-up turn can resume it (see [Hermes agent memory](#hermes-agent-memory)). A store untouched for `MULTICA_GC_HERMES_SESSION_TTL` is removed. The default matches the Codex session store rather than the memory store above: these hold full transcripts, and reclaiming an idle one costs a thread that starts fresh (with a continuity notice), not an agent that forgot what it learned. A store a running task holds is never reclaimed.
 - **Hermes memory store reclamation** — a Hermes agent's long-term memory (`memories/`) lives at `<profile dir>/hermes-state/<agent-id>/<hermes-profile>/`, outside any task directory, so it survives across tasks and issues (see [Hermes agent memory](#hermes-agent-memory)). A store untouched for `MULTICA_GC_HERMES_MEMORY_TTL` is removed, giving a deleted agent's memory an eventual-reclamation guarantee. The default is deliberately long: these are a handful of markdown files, and reclaiming one is user-visible amnesia rather than a cache miss. A store a running task holds is never reclaimed.
-- **Task temp dir reclamation** — every task gets a private temp directory (`multica-task-*`) under the system temp base (`/tmp`, or `MULTICA_AGENT_TEMP_BASE`), exported to the agent as `TMPDIR`/`TMP`/`TEMP`. It is removed when the run ends, but that removal never happens when the daemon is killed and does not succeed while a file inside is still open — common on Windows, where an open handle makes the delete fail outright. These directories live outside `MULTICA_WORKSPACES_ROOT`, so nothing else reclaimed them and whatever the end-of-run removal missed accumulated forever. Every GC cycle now sweeps the temp base. Liveness is decided by the directory's `.task_lock` — the same OS advisory lock an env root uses, which the kernel releases when the holding process dies — not by age: a directory still in use is never removed however old it is, including one owned by a different daemon sharing the same temp base, and a directory whose owner is gone is removed on the next cycle however new it is. Directories left by a daemon predating that lock carry no lock file, so nothing can be proven about them and age is the only signal available. Reclaiming those is an operator's explicit decision: `MULTICA_GC_TASK_TEMP_LEGACY_TTL` defaults to `0`, which leaves them in place. Set it to a duration only once you know no pre-lock daemon is still running tasks on this machine — a task may legitimately run for weeks (there is no default agent timeout), a daemon on another profile can still be on the old binary, and every daemon on the machine shares one temp base, so a TTL here can delete a `TMPDIR` that is still in use. Each GC cycle logs how many such directories it left alone. Even with a TTL set, a directory holding no task content is never reclaimed on age — an old empty leftover, or a shell left by a daemon that died between creating the directory and publishing its lock — because holding no content is exactly what a directory currently being published looks like, and deleting one of those would take the `TMPDIR` of a task that is starting. Those shells are a few bytes each. Only entries carrying the `multica-task-` prefix are ever considered — the temp base itself is usually shared with other programs — and a directory this sweep cannot read is never touched.
+- **Task temp dir reclamation** — every task gets a private temp directory (`multica-task-*`) under the system temp base (`/tmp`, or `MULTICA_AGENT_TEMP_BASE`), exported to the agent as `TMPDIR`/`TMP`/`TEMP`. On Windows, every task instead inherits the daemon user's `TMP`/`TEMP`: Git Bash's `/tmp` mount is shared by all of the user's live Git Bash processes, whichever runtime started them, so it must never point at a task directory that will be deleted. `TMPDIR` stays task-local, and for Claude Code `CLAUDE_CODE_TMPDIR` defaults to that directory unless the user overrides it. It is removed when the run ends, but that removal never happens when the daemon is killed and does not succeed while a file inside is still open — common on Windows, where an open handle makes the delete fail outright. These directories live outside `MULTICA_WORKSPACES_ROOT`, so nothing else reclaimed them and whatever the end-of-run removal missed accumulated forever. Every GC cycle now sweeps the temp base. Liveness is decided by the directory's `.task_lock` — the same OS advisory lock an env root uses, which the kernel releases when the holding process dies — not by age: a directory still in use is never removed however old it is, including one owned by a different daemon sharing the same temp base, and a directory whose owner is gone is removed on the next cycle however new it is. Directories left by a daemon predating that lock carry no lock file, so nothing can be proven about them and age is the only signal available. Reclaiming those is an operator's explicit decision: `MULTICA_GC_TASK_TEMP_LEGACY_TTL` defaults to `0`, which leaves them in place. Set it to a duration only once you know no pre-lock daemon is still running tasks on this machine — a task may legitimately run for weeks (there is no default agent timeout), a daemon on another profile can still be on the old binary, and every daemon on the machine shares one temp base, so a TTL here can delete a `TMPDIR` that is still in use. Each GC cycle logs how many such directories it left alone. Even with a TTL set, a directory holding no task content is never reclaimed on age — an old empty leftover, or a shell left by a daemon that died between creating the directory and publishing its lock — because holding no content is exactly what a directory currently being published looks like, and deleting one of those would take the `TMPDIR` of a task that is starting. Those shells are a few bytes each. Only entries carrying the `multica-task-` prefix are ever considered — the temp base itself is usually shared with other programs — and a directory this sweep cannot read is never touched.
 
 Configured patterns are basename-only — entries containing `/` or `\` are silently dropped — and `.git` subtrees are never descended into. The managed Codex cache is matched by its exact relative path, so a repository's own `.sandbox-bin` is not removed unless an operator explicitly adds that basename to `MULTICA_GC_ARTIFACT_PATTERNS`. The default list (`node_modules`, `.next`, `.turbo`) is intentionally narrow; extend it per deployment if your repos consistently produce other regenerable directories (for example, `MULTICA_GC_ARTIFACT_PATTERNS=node_modules,.next,.turbo,target,__pycache__`). To disable artifact cleanup entirely, including the managed Codex cache, set `MULTICA_GC_ARTIFACT_TTL=0`.
 
@@ -457,7 +508,7 @@ multica daemon start --profile staging
 multica daemon start
 ```
 
-Each profile gets its own config directory (`~/.multica/profiles/<name>/`), daemon state, health port, and workspace root. Daemon state means that profile's own `daemon.log`, `daemon.err.log`, and `daemon.pid` live in that directory too — see [Start](#start) for the layout, and pass `--profile <name>` to `daemon status` / `daemon logs` to act on it.
+Each profile gets its own config directory (`~/.multica/profiles/<name>/`), daemon state, health port, and workspace root. Daemon state means that profile's own `daemon.log`, `daemon.err.log`, `daemon.pid`, and `daemon.port` live in that directory too — see [Start](#start) for the layout, and pass `--profile <name>` to `daemon status` / `daemon logs` to act on it. The daemon normally uses the profile-derived health port. If the OS refuses that port, it binds an available loopback port and records the actual port in `daemon.port` for lifecycle commands. The record is valid only while its daemon is alive; do not edit it to configure a port.
 
 ## Workspaces
 

CONTRIBUTING.md

@@ -44,7 +44,7 @@ This keeps Docker simple while still isolating schema and data.
 
 - Node.js `22`
 - `pnpm` `10.28.2`
-- Go `1.26.6`
+- Go `1.26.9`
 - Docker
 
 ## Important Rules

Dockerfile

@@ -1,5 +1,5 @@
 # --- Build stage ---
-FROM golang:1.26-alpine AS builder
+FROM golang:1.26.9-alpine AS builder
 
 RUN apk add --no-cache git
 

Dockerfile.web

@@ -8,6 +8,8 @@ COPY pnpm-lock.yaml pnpm-workspace.yaml package.json turbo.json .npmrc ./
 COPY apps/web/package.json apps/web/
 # postinstall runs fumadocs-mdx which reads apps/web/source.config.ts
 COPY apps/web/source.config.ts apps/web/source.config.ts
+# Root pnpm patchedDependencies is read even without the mobile workspace.
+COPY apps/mobile/patches/ apps/mobile/patches/
 COPY packages/core/package.json packages/core/
 COPY packages/ui/package.json packages/ui/
 COPY packages/views/package.json packages/views/