/ctx-status "Cache TTL" shows the DB seed value ("5m"), not the effective config, until the first assistant message_end

[G0-0000]

What happened?

After a restart or new session, /ctx-status reports Cache TTL: 5m even when the config sets a different value (e.g. "cache_ttl": "1h"). The displayed value is only corrected after the first full assistant response completes. This makes /ctx-status misleading exactly when users check it most — right after changing config or restarting, to verify the new setting took effect.

Root cause (0.41.2):

• /ctx-status reads Cache TTL from SQLite session_meta.cache_ttl (render at dist/index.js L29478: Cache TTL: ${s.cacheTtl} …), not from the live config.
• The session_meta row is created with a hardcoded seed: getDefaultSessionMeta() sets cacheTtl: "5m" (dist/index-ys39wb43.js L15266-15270) and ensureSessionMetaRow inserts it via INSERT OR IGNORE (L15323-15324).
• The row is only synced to the effective config in persistPiMessageEndModelMeta (dist/index.js L30441-30455): on the first assistant message_end event carrying provider+model, it calls resolveCacheTtl(args.cacheTtlConfig, modelKey) and updateSessionMeta if different. There's also a read-side fallback row.cache_ttl || "5m" (L15329) so even an empty column shows 5m.

So the displayed TTL is stale-by-design between session start and the first completed assistant turn. Combined with config-parse issues (which also revert TTL to the 5m default), this caused real diagnostic confusion: we changed cache_ttl to 1h, restarted, saw 5m, and initially concluded the config wasn't being applied.

Expected: Any of:

• Seed session_meta.cache_ttl from the resolved config at session start (config is already loaded at plugin boot), not "5m", or
• Have /ctx-status resolve TTL from the live config directly (it's display-only state; the DB row can remain the runtime cache), or
• Annotate the line, e.g. Cache TTL: 5m (not yet synced — resolves after first response).

Diagnostics

doctor --issue unavailable: `npx @cortexkit/magic-context@latest doctor --issue --harness pi` launched an interactive TUI (prompted for Issue title: "Short summary of the Pi problem") instead of dumping diagnostics to stdout or a report file; exit 0, no issue-report file produced.

Non-interactive `npx @cortexkit/magic-context@latest doctor --harness pi` output (2026-09-08):

Running doctor for Pi…
Magic Context for Pi Doctor
PASS Pi 0.84.4 detected at /home/g0/.local/bin/pi
PASS Pi version meets minimum 0.74.0 requirement
PASS Magic Context Pi CLI v0.41.2 is current (npm latest v0.41.2)
PASS Pi settings found at /home/g0/.pi/agent/settings.json
PASS npm:@cortexkit/pi-magic-context is registered in packages[]
PASS user magic-context.jsonc is valid JSONC: /home/g0/.config/cortexkit/magic-context.jsonc
INFO No project Magic Context config found at /home/g0/ttt/.cortexkit/magic-context.jsonc
PASS Pi Magic Context config loads successfully
INFO Shared storage: /home/g0/.local/share/cortexkit/magic-context (source: platform default)
PASS Shared context DB exists at /home/g0/.local/share/cortexkit/magic-context/context.db
PASS Opened shared DB read-only supported schema
INFO Storage versions: context_db_schema_version=83, plugin_supported_version=83
INFO Upstream migration fence: context.db and build are both v83.
PASS SQLite integrity_check: ok
INFO Shared DB row counts: tags=64144, compartments=85, memories=308, notes=14, dream_runs=335
PASS Embedding endpoint OK (200, 2560-dim vectors)
PASS No conflicting magic-context entries in Pi packages[]
INFO Other Pi extensions registered: npm:pi-subagents, git:github.com/Leechael/pi-provider-kimi-code, npm:@ff-labs/pi-fff, npm:@victor-software-house/pi-curated-themes, npm:pi-open-tui, npm:pi-mcp-adapter, npm:pi-rtk-optimizer, npm:@juicesharp/rpiv-ask-user-question, npm:@tmustier/pi-usage-extension, npm:pi-cache-guardian
INFO log: /tmp/pi/magic-context/magic-context.log (3887 KB)
INFO [2026-09-04T17:53:05.266Z] projects=1
PASS 13  WARN 0  FAIL 0

Plugin version: 0.41.2

OpenCode version: N/A

Platform: linux x64

Client: Pi

[magic-alfonso]

Thanks for the precise report. Your 0.41.2 source cites were exact. The current source confirms the same mechanism: getDefaultSessionMeta() seeds cacheTtl: "5m", ensureSessionMetaRow() inserts that value, and row conversion uses row.cache_ttl || "5m" semantics (packages/plugin/src/features/magic-context/storage-meta-shared.ts:307-316, :365-389, :408-416). The first model-bearing assistant completion was the later correction point.

This is fixed on master and ships in 0.41.4 (0.41.3 was already cut when this landed) on both OpenCode and Pi:

• Status display now resolves against live config plus the current model while the row is unsynced, and labels the source: Cache TTL: 1h (config for anthropic/claude-opus-5), Cache TTL: 1h (session), or Cache TTL: 5m (default — no cache_ttl for <model>). OpenCode RPC uses the persisted model key to decide whether the row is current (packages/plugin/src/plugin/rpc-handlers.ts:730-743, :805-841); Pi /ctx-status uses the same resolver (packages/plugin/src/hooks/magic-context/execute-status.ts:105-134).
• Pi seeds an unsynced session row during session_start when ctx.model is available (packages/pi-plugin/src/index.ts:1337-1362). OpenCode applies the same safe seed on the first model-bearing user message. The completed assistant path remains the correction/ownership point.
• The scheduler path is unchanged: it still reads session_meta.cache_ttl. The new resolver is status-only, and the early seed refuses to overwrite a row once a completed-response model owns it. Tests pin that a status read cannot mutate the row.
• /ctx-status also places any config parse failure first, so a real default and an ignored/recovered config are no longer visually indistinguishable (packages/plugin/src/hooks/magic-context/execute-status.ts:149-155).

The related doctor side finding is fixed in the same patch: doctor --issue --harness pi --report <path> writes a sanitized report bundle without prompting (packages/cli/src/commands/doctor-pi.ts:1049-1073).