notifications: non-interactive `notify setup` always fails to activate the daemon, persists the settings anyway, and reports "Unable to persist"

[yazzang-homelab]

Version: gjc/0.12.7 (installed), Linux, source-mode Bun runtime.

Summary

gjc notify setup --token … --chat-id … (non-interactive) fails at daemon activation:

Token validated. Message your bot now from the private Telegram chat to pair notifications.
Warning: Telegram Threaded Mode capability is OFF for this bot. Setup will be saved because this run is non-interactive.
Using provided chat id <redacted> (non-interactive).
Error: Unable to persist and activate Telegram notification settings:
       Telegram daemon provisional ownership could not be retired safely

Two defects here, and they are separable:

1. The settings are persisted despite the "Unable to persist" wording. gjc notify status
   immediately afterwards reports enabled: true, telegram.configured: yes, fingerprint stored.
   Outbound notifications work from that moment (gjc notify test → OK — delivered).
2. The daemon never becomes ready, so inbound (button/reply) handling is dead, and every run
   leaves telegram-daemon.{lock,steal,state.json} behind.

This is not the 409 / competing-poller case

First observed on a bot token that another process was polling, so a 409 story looked plausible.
Verified false. Reproduced on a brand-new bot created minutes earlier, with no other poller:

getMe      → ok: True, username <fresh bot>
getUpdates → ok: True, error: None, updates: 0     # no 409, no competitor
sendMessage→ ok: True                              # chat reachable
gjc notify setup --token … --chat-id … --redact
           → Error: Unable to persist and activate … provisional ownership could not be retired safely
gjc notify status → enabled: true, telegram.configured: yes
gjc notify test   → OK — delivered to chat …

So the failure is unconditional on this host, not contention-dependent.

Post-failure state

// notifications/telegram-daemon.state.json
{ "pid": 111629, "ownershipPhase": "provisional",
  "startedAt": 1785710585165, "heartbeatAt": 1785710585165,   // never advanced
  "generation": 38, "servingEpoch": 4 }

• notifications/daemon.log — 0 bytes; the child never logged anything.
• No daemon-internal process alive.
• notify health → daemon owner pid 111629 is not alive; run recovery to clear the stale lock.

gjc notify daemon-internal --owner-id <live-pid>-probe --agent-dir … also exits immediately with
status 0 and no output on either stream, so the daemon entrypoint has at least one silent-exit path
with no diagnostic (telegram-daemon-cli.ts runDaemonInternal, e.g. the ownerProcessIsAlive
early return only calls logger.warn, which goes nowhere for a detached child whose log file stays
empty).

Message/rollback contract

packages/coding-agent/src/cli/notify-cli.ts:470-536:

const receipt = await settings.commitAtomicBatch(patches);   // :477 values land here
settingsCommitted = true;                                    // :478
const activation = await reconcileCommittedTelegramConfiguration({ … });  // :485
if (activation.status === "blocked_identity") { … await activation.restore(); … }  // :511 only rollback
if (activation.status === "activation_failed") { receipt.discard(); throw new Error(activation.message); }
} catch (error) {
    throw new Error(
        settingsCommitted
            ? `Telegram notification settings were saved, but activation or recovery failed: ${detail}`
            : `Unable to persist and activate Telegram notification settings: ${detail}`,   // :534 ← printed
    );
}

The settingsCommitted === false branch printed while the values are on disk, so the flag does not
describe durable state on this path. Only blocked_identity restores anything; a thrown activation
leaves the config armed.

Compare the interactive pairing path, which guarantees the opposite for its failure class
(packages/coding-agent/src/sdk/bus/telegram-setup.ts:459-463):

"Telegram setup stopped because another poller owns this bot. No configuration was saved."

Why it matters

The operator reads "Unable to persist", assumes nothing happened, and moves on. Telegram is in fact
enabled. If the token belongs to a bot another product already polls, the next gjc session starts a
daemon that competes for getUpdates on it — the #3587 failure mode, reached silently through setup.

Suggested fix (two independent slices)

Slice 1 — message/rollback contract (small, testable now).
Derive the failure wording from durable state observed after the failure, and roll back the committed
patches for every non-success activation outcome, not just blocked_identity. "Unable to persist"
must be impossible to print while notify status reports configured.

Slice 2 — daemon activation on a source-mode runtime (needs maintainer input).
The daemon child never reaches ready and leaves ownership provisional. One candidate:
buildTelegramDaemonSpawnArgs / spawnTelegramDaemonOwner
(packages/coding-agent/src/sdk/bus/telegram-daemon.ts:3182-3209) only substitutes an opaque
daemon-<uuid> owner id for runtimeInfo.mode === "source" && platform === "win32", with the comment

// On Windows, a source-linked Bun/Node detached child can begin after its
// short-lived CLI parent has exited. Keep the owner id opaque so the
// daemon-internal launcher does not mistake that parent PID for its owner;

The same short-lived-parent shape exists for a source-mode Bun CLI on Linux (notify setup exits
right after spawning), where the guard does not apply. This is a hypothesis, not a verified root
cause — the silent-exit path makes it unobservable from the outside, which is itself worth fixing.

Tests worth adding

• non-interactive setup + activation failure → notifications.telegram.botToken /
  notifications.enabled unchanged.
• invariant: the thrown wording matches what notify status reports afterwards.
• runDaemonInternal early-exit paths write a durable diagnostic to notifications/daemon.log
  instead of a logger sink that a detached child discards.

Related: #3587, #2956.

[yazzang-homelab]

Follow-up: the child is spawned, and it dies inside TelegramNotificationDaemon.run() before any logging

Additional bisection on the same host. Two claims from the original report need correcting, and the silent-exit path is now narrowed to a single call.

1. The daemon child is spawned — it just exits immediately

Polling ps every 150 ms during notify setup catches it:

487859  487791  00:00 /root/.bun/bin/bun \
  /root/.bun/install/global/node_modules/@gajae-code/coding-agent/bin/gjc.js \
  notify daemon-internal --owner-id 487791-mscfwbh3-l8mx95rp91 --agent-dir <agentDir>

It is gone on the next poll, notifications/daemon.log stays 0 bytes, and nothing reaches the logger sink (~/.gjc/logs/gjc.<date>.log has no child-side line at all).

2. The exit is inside run(), not in the runDaemonInternal guards

Driving the daemon in-process against the real agent dir:

const s = await loadLightweightDaemonSettings(AGENT_DIR);
const cfg = getNotificationConfig(s);
// isProviderEffectivelyEnabled(cfg,"telegram") === true, isTelegramComplete(cfg) === true
// resolveNotificationProvider → {configured:true, quarantined:false, desiredEnabled:true, effectiveEnabled:true, issues:[]}
const daemon = new TelegramNotificationDaemon({ settings: s, ownerId, botToken: cfg.botToken, chatId: cfg.chatId, pid: process.pid, … });
await daemon.run();   // returns after 4 ms

• with a forged provisional state whose pid/incarnation/ownerId are the probe's own, plus a matching lock file → run() returns in 4 ms
• with state owned by a different live pid → run() returns in 111 ms

Both return before startLifecycleControl(), so the only exits reachable that early are validBotToken() (the token is a normal 46-char <id>:<secret>, so this passes) and if (!renewed) return; from renewDaemonHeartbeat(...) — telegram-daemon.ts:10696-10710. renewDaemonHeartbeat returns false from several places without a single log line, so from the outside the daemon is indistinguishable from "never started".

Ask: even if the ownership refusal is correct, it should not be silent. A one-line reason on the child's stderr (which the launcher can capture into notifications/daemon.log) would have turned this whole investigation into one command.

3. The first failure poisons every later attempt

Once the launcher leaves a provisional record behind:

notifications: failed to ensure Telegram daemon: telegram daemon ownership is provisional; refusing to attach

and the next notify setup no longer spawns anything:

Error: … Telegram activation remains blocked by a foreign daemon; previous settings were restored.

Combined with #3762 (notify recovery answering left-contended for a dead owner), the only exit is deleting telegram-daemon.{lock,steal,state.json} by hand. After deleting them, the next notify setup spawns a child again — and the cycle repeats.

4. Separate divergence worth a look: the child reads only config.yml

loadLightweightDaemonSettings() (telegram-daemon-cli.ts) parses <agentDir>/config.yml and nothing else, and runDaemonInternal returns silently at

if (!isProviderEffectivelyEnabled(cfg, "telegram") || !isTelegramComplete(cfg)) return;

The parent CLI resolves notification settings through the full Settings stack. Any state where the parent considers Telegram configured but config.yml does not carries the same symptom — a child that exits with status 0 and no output. That guard deserves a diagnostic too.

Environment note

Multi-account layout (~/.gjc-accounts/<name>/agent) where several accounts symlink notifications/ to a shared directory while keeping separate config.yml. The reproduction above pins the active account's own agent dir, so the shared directory is not the cause of the 4 ms return, but it does mean one stale provisional record can block several accounts at once.

[Yeachan-Heo]

Terminal validation update — exact current-dev evidence, no private credentials used.

Disposition: BLOCKED for implementation under the agreed gate. #3761 requires two controlled live Linux source-mode attempts using a fresh disposable maintainer-controlled bot/chat and isolated agent directory. No disposable Telegram credentials are available to this lane, so those attempts were not performed and no speculative source-mode fix is being shipped.

Current-dev trace: spawnTelegramDaemonOwner on source mode leaves the owner ID PID-prefixed unless the Windows-only opaque-owner branch applies (packages/coding-agent/src/sdk/bus/telegram-daemon.ts); runDaemonInternal derives a PID from PID-prefixed owner IDs and returns before daemon construction when that PID is not alive (packages/coding-agent/src/sdk/bus/telegram-daemon-cli.ts). This is a strongly-supported causal hypothesis, not a confirmed root cause. Existing focused notification tests pass on current dev, but they do not substitute for the required live reproduction.

Exact blockers: missing disposable maintainer-controlled bot/chat credentials and therefore no safe live Telegram boundary test. No tokens, chat IDs, or private artifacts are included here. Signed via terminal GitHub CLI as Yeachan-Heo.

[Yeachan-Heo]

ADMITTED / NOT A DUPLICATE / KEEP OPEN

Triage refreshed against current dev 732856b3ccb3fade6e9fbc17908a4fbca5a7682f.

Admission

Admitted, qualified. yazzang-homelab supplied a concrete gjc/0.12.7 Linux source-mode reproduction, ruled out a competing poller with a fresh bot, and narrowed the incident to a spawned child that exits before readiness while durable configuration and outbound delivery remain functional. That is sufficient to admit the incident. It is not yet a confirmed exact-current-dev regression or confirmed PID-owner root cause because the maintainer-required two controlled live attempts were never run.

Duplicate status

Not a full duplicate.

• notifications: notify recovery reports left-contended forever for a provably dead owner while notify health keeps advising "run recovery" — no diagnostic, no escape hatch, manual rm only #3762 is the downstream stale-provisional-owner recovery dead end created after this activation failure; fix(notifications): diagnose and safely retry dead-owner recovery #3768 resolves that recovery/diagnostic slice, not activation.
• Telegram daemon: closing one gjc tui can orphan a poller that races the next session's fresh daemon (409 conflicts + stale-button floods) #3587 is the competing-poller mode explicitly ruled out by the fresh-bot reproduction.
• Telegram daemon silently degrades and stops emitting: notification-root leak + unbounded transition/placeholder artifacts, not recoverable by daemon reload #2956 is related background only; the supplied evidence does not establish duplication.

Resolved slices and contributor ledger

• Reporter/investigator yazzang-homelab authored merged fix(notify): report a failed Telegram setup by durable state, not code path #3763 (aebb0f6d119acf178a9c710f460f83e9735bb8e6), which fixes the false Unable to persist wording by observing durable state. It explicitly does not implement rollback or fix daemon activation.
• Maintainer Yeachan-Heo authored merged fix(notifications): diagnose and safely retry dead-owner recovery #3768 (57577acd7ea2da991024604e92bb209f3a30c7d5), which resolves notifications: notify recovery reports left-contended forever for a provably dead owner while notify health keeps advising "run recovery" — no diagnostic, no escape hatch, manual rm only #3762's dead-owner recovery classification, bounded stale-marker reclaim, force retry, and recovery diagnostics. It explicitly includes no notifications: non-interactive notify setup always fails to activate the daemon, persists the settings anyway, and reports "Unable to persist" #3761 source-mode activation fix.

Remaining closure gate

Keep this issue open until the owner completes two isolated live Linux source-mode attempts on exact current dev with a fresh disposable maintainer-controlled bot/chat and agent directory, capturing:

1. child exit/startup diagnostics;
2. ownership transition from provisional to ready;
3. daemon readiness; and
4. one inbound button/reply round trip.

If the failure reproduces, confirm and fix the cause, then repeat the live proof. If both clean attempts falsify it, document the exact environment/version delta. Closure must also state the retained-configuration policy accurately: #3763 chose truthful retain-and-report behavior and did not add rollback.

Current owner path

The remaining gate requires maintainer-controlled Telegram assets, so the accountable owner is Yeachan-Heo. Preserve yazzang-homelab's explicit credit as reporter, investigator, and author of the merged reporting fix; the contributor is not accountable for a credential gate only a maintainer can satisfy.

gajae.issue-triage.v1 KEEP_OPEN issue:3761 dev:732856b3ccb3fade6e9fbc17908a4fbca5a7682f admission:ADMITTED duplicate:NO owner:Yeachan-Heo reviewer:Yeachan-Heo

Signed: GJC / Yeachan-Heo via GitHub CLI