Repository navigation
Skill workflows stall or run away in the app across Cursor and Anthropic models #3
Description
Activity
App-side command transport and CI blockers have now been remediated in #7–#9. The remaining deep-interview, ralplan, and ultragoal failures are owned by the pinned coding-agent workflow/tool lifecycle. No app-side fallback executor was added. Remaining work requires direct SDK reproduction and an upstream fixed release, followed by the acceptance scenarios already listed in this issue.
Current status: this report predates the interactive-prompt and permission rework (beta.5-beta.8). The two runaway patterns it names — the runtime probing shell state instead of asking, and gates never reaching a terminal state — now have dedicated paths: tool asks render as cards with allow/deny, OAuth and Chromium prompts use the same select UI, and Stop works from the moment a run is accepted. That does not prove every bundled skill completes; it changes the failure modes enough that the beta.3 table is stale. Next step on our side is re-running this skill matrix against beta.8 and converting each surviving failure into its own issue. Keeping this open as the tracking issue until that matrix exists.
Root-cause analysis against current main + the pinned runtime (0.15.6). Three distinct causes, two of them shared with #18:
A. Corrupt workflow session identity (= #18)
The SDK tool session's
getSessionId()returns the AsyncJobManager endpoint key — a JSON tuple for app sessions — and the runtime's bash tool injects it asGJC_SESSION_IDinto every spawned command (buildGjcRuntimeSessionEnv). So even a workinggjc statesubprocess was pointed at the corrupt.gjc/_session-["async-job-endpoint",...]tree: state written in one turn was invisible the next, which is exactly the deep-interview/ralplan "stall" pattern (the model re-probes, self-diagnoses missing output, never reaches a terminal state). Fixed upstream in Yeachan-Heo/gajae-code#5282; lands here with the next pin bump.B. No
gjcon PATH inside app sessionsThe bundled skills (
deep-interview,ralplan,ultragoal,autoresearch) drive their state machine throughgjc state <skill> ...shell commands. In the app those run in the session's bash environment, which is the app server's environment — a machine without a global gjc install (the CUA sandbox, any end user) getscommand not found, and the model flails throughwhich gjc, redirects, and CLI help exactly as the report shows. On the maintainer's machine a global~/.local/bin/gjcmasks this — and worse, it's a different runtime than the app's pinned one.Fix in progress: the worker already resolves a pinned bun (
runtime.bunPath ?? dist-native/bun) and session bash inherits the worker'sprocess.env, so the app will ship a shim directory on the worker's PATH with agjcwrapper that invokes the pinned runtime'sbin/gjc.jsunder the pinned bun — session-scoped state commands then work identically in dev, self-hosted, and packaged installs.C. ultragoal
goal {}+ quality-gate runawayThe
goaltool was invoked with empty arguments (a model-side error the validation layer correctly rejected) and the run continued ~49k tokens past verified completion. A+B remove the state-loss excuses that feed this loop (quality gates re-verifying unreadable state), but the completion-boundary behavior itself needs a CUA re-run once A+B land before we call it fixed.teamstaying hidden/refused is the expected behavior and matches the report.Keeping this open until the shim (B) and the pin bump (A) land and the skill matrix is re-run in the sandbox.
Closing per owner decision (2026-09-10).
The three root causes identified in the 2026-09-04 analysis were addressed by the follow-up implementation that has since landed: goal state now comes from the SDK transcript with authenticated, scoped pause/resume/cancel controls and app-owned delegation (permissions/account/model/effort inheritance, workflow guards, cancellation), and the workflow step lease was raised from 20 to 200. See
GJC-DELEGATION-CONTRACT.mdand the session handoff for the exact contract.What was never done is the final live qualification across Cursor/Anthropic models — the owner excluded cross-model live skill testing, so this is closed as addressed-by-design rather than proven live. If a user report shows deep-interview/ralplan/ultragoal still stalling or running away on current builds, open a fresh issue with the model and session evidence and it will be handled there.
Summary
CUA testing of every bundled skill exposed workflow execution failures in the web app. Skill selection and the Run confirmation gate work, but the executable workflows do not reliably reach their terminal user-facing state.
Environment
v2.0.0-beta.3README.mdcursor/cursor-grok-4.6-xhigh-fast,anthropic/claude-fable-5Results
deep-interviewgjc deep-interview read,which gjc, shell redirects, and CLI help while reporting missing/incomplete command output. Had to stop manually.ralplan --deliberatepwd,ls,which gjc, environment variables, andfind, while reporting that normal shell output was empty. Had to stop manually.ultragoalgoaltool as{}and hit validation failure (opmissing). It then continued through an oversized quality-gate flow, displayed a quality-gate write error, consumed about 49,290 tokens, and was still running after the requested file was verified. Had to stop manually.team/skill:teamis refused with the tmux/ultragoal guidance.Reproduction
/skill:<name>command.Ultragoal goal-tool error:
Expected
deep-interviewreaches one user-facing question without repeatedly probing its own CLI.ralplanproduces its persisted receipt and approval boundary.ultragoalcallsgoalwith valid arguments, completes once the bounded goal and quality checks pass, and does not consume tens of thousands of tokens for a one-line file.