Repository navigation
local_refusal (hidden_prompt_unrecognized) bypasses dreamer fallback_models — single model tried #647
Description
Activity
Thanks for the clear report and the run evidence.
The refusal comes from a safety check added in 0.46.1: a background dreamer turn that didn't receive its task setup is stopped before the model runs. Without that check, a background session on another host once ran with the user's tool permissions and edited files (#639). So the check itself is intended. What isn't intended is that
retrospectiveandcurateconsistently reach it on your OMP host, while the other tasks get their setup normally.We're investigating why those two tasks don't get their setup on OMP. On fallbacks: if the setup is missing for the task itself rather than for a particular model, trying the next model would hit the same refusal. In that case the right fix is the setup path, plus an error that names the task and the step that was missed, so it's actionable.
Could you share your OMP version (
omp --version), and the Magic Context log lines around one failedretrospectiverun? The log is under your temp directory, inomp/magic-context/magic-context.log.An update. The exact error you're seeing can only be raised by Magic Context's OpenCode 2 code path. OMP runs dreamer tasks a different way and can't produce it, and the child session id in your report has OpenCode's format. So these failing runs most likely came from an OpenCode 2 instance that also has this project open, not from OMP.
We ran all six dreamer tasks on real OpenCode 2.0.24 and OMP 18.8.6, manually and on the timer, across two project folders, with
retrospectiveandcuratedoing real tool work. All of them completed, so we haven't reproduced your case yet. The next release changes the error to name the task, the child session, its folder and the step that was missed, so a failure points at the cause.To narrow it down:
- Do you also run OpenCode 2 on this project? If so, which version (
opencode --version)? - Please share the Magic Context log lines from that OpenCode process around one failed
retrospectiveorcuraterun. On OpenCode they're in your temp folder underopencode/magic-context/magic-context.log. - Was that run started by
/ctx-dreamor by the schedule?
On fallbacks: this failure comes from the task's setup, not the model, so trying another model wouldn't fix it. That's why it stops instead of moving through your fallback list.
- Do you also run OpenCode 2 on this project? If so, which version (
0.47.0 is out. A dreamer task stopped before its setup now names the task, the background session, its folder and the step that was missed. This failure means the host did not apply Magic Context's setup to the background session, so trying another model would hit the same thing, which is why the fallback models are not used for it. If it happens again on 0.47.0, please share that error line.
Update to 0.47.0 (OpenCode:
opencode-magic-context@0.47.0; Pi and Oh My Pi:@cortexkit/pi-magic-context@0.47.0). There is no database migration, so restarting the host is enough. OpenCode 2 needs 2.0.22 or newer and does not update plugins on its own: open/plugins, select Magic Context and press ctrl+u. Release notes: https://github.com/cortexkit/magic-context/releases/tag/v0.47.0Confirmed attribution from local DB: runs 10273–10329 are all
dir:b0c0de5ba7d9, which has 0ompsession rows (346 opencode + 455 opencode2) — so yes, these came from OpenCode Desktop, not OMP. Failing childses_edff7a...never mapped insession_projects; allses_ed%rows here areopencode2.Versions at failure time were 0.46.1; both hosts are now on 0.47.0 (OMP
pi-magic-context+ Desktopopencode-magic-contextdep). Nolocal_refusalindream_runssince Oct 9 09:39 UTC; latest retrospective (10372) completed. Will share the new 0.47.0 error line (task + session + folder + missed step) if it recurs.One related observation: on the OMP host the dreamer drops all
opencode/*fallback models at registration (dropping Pi model not found), leaving a primary-only chain there by construction. Desktop fallback works for per-model errors (run 10366 tried all 4). Oct 9 failure logs in/tmphave rotated, but I have the fulltasks_jsonrows if you want them.Setup:
omp/18.8.8,opencode 1.18.30, Desktop serveopencode v2.0.26; runs were schedule ticks, not/ctx-dream.Thanks for confirming the attribution. That matches what we found: those runs came from the OpenCode 2 host, not OMP.
On the OMP fallback models: that drop is expected.
opencode/*models are served by OpenCode's own provider, which Pi and OMP don't have, so the dreamer on OMP removes them and logsdropping Pi model not found. To give OMP a fallback chain, list models under their Pi provider names in thepiorompdreamer block. On OMP,/ctx-statuswarns when a dreamer task or the historian has no usable model left, and the log names each model it dropped.We'll keep this open for a bit. If it happens again on 0.47.0, the new error line (task, session, folder and the step that missed) is what we need.
Symptom
retrospective+curateon an OMP project fail withHiddenCompletionRefusal(hidden_prompt_unrecognized: Host did not dispatch the hidden child context hook),failure_class: local_refusal. Dashboard shows them red;map-memorieson the same project completes fine minutes apart, so the host/child channel itself works.The bug: fallbacks never engage
dreamer.omphas a 4-model chain (primaryopencode-go/muse-spark-1.3-contributor+ 3fallback_models), yet every failing run recordsmodels_tried: [primary]— length 1, 8 consecutive runs over 2 days (run ids 10273–10329). The refusal is thrown before fallback iteration, so the chain is dead config for this failure class.Evidence
failure: {failure_class: local_refusal, model_attempted: opencode-go/muse-spark-1.3-contributor, models_tried: [same], provider_error: null, child_session_id: ses_edff7a007ffe4HiBIV0Mn1K4bv present}— a child session WAS created, the hook dispatch never happened.verify/classify-memories/promote-primerssucceed on the same host in the same window — refusal is route-specific (tool-requiring tasks: retrospective + curate), not host-wide.harness=omp (via process-title)confirmed in log); this is the remaining failure on a correctly-labeled host.Suggestion
Treat
local_refusallike a provider error for fallback purposes (try next model), or surface which hook/contract version the host missed so omp can fix its side — right now the error gives the user nothing actionable.