Skip to content

Feature idea: extend /goal with intent calibration, evidence chains, and side-thread tolerance #20958

Open
Open
Feature idea: extend /goal with intent calibration, evidence chains, and side-thread tolerance#20958
Labels
enhancementNew feature or request

Description

@huahuadeliaoliao
huahuadeliaoliao
opened on May 4, 2026

What variant of Codex are you using?

Codex CLI with local skills and hooks enabled.

What feature would you like to see?

I would like /goal to grow an optional long-run harness layer inspired by a userland Codex skill I have been building: Long Long Run (LLR).

LLR repo:
https://github.com/huahuadeliaoliao/long-long-run

Origin story / design notes:
https://github.com/huahuadeliaoliao/long-long-run/blob/main/docs/why-long-long-run.md

Codex 0.128.0's persisted /goal workflows are a strong foundation for long-running work. In practice, though, the hard part is often not only remembering that a goal exists. The harder parts are:

  • helping the user clarify the real goal before execution
  • reducing intent noise when the user does not know the domain well enough to define the right target
  • turning vague intent into a concrete, evidence-backed contract
  • tracking which evidence still supports the current plan
  • tolerating side questions or late constraints without losing the mainline
  • avoiding premature stops when Codex already knows the next goal-covered action
  • encouraging real domain exploration before simply validating an answer Codex already expects

LLR experiments with this through two modes:

  • INC mode: Intent Noise Cancellation. Codex explores the repo/domain, surfaces assumptions, identifies risks, discovers expert framing, proposes hard acceptance criteria, and builds an evidence-backed contract before implementation.
  • ACTIVE mode: the user explicitly authorizes Codex to pursue the confirmed contract as the mainline. Codex should continue through clear contract-covered next steps instead of stopping after every useful local update.

The feature I would like to see is not necessarily LLR copied into Codex directly. Rather, I would like /goal to support similar long-run harness semantics, either as built-in behavior or as extension points for skills/plugins.

A possible model:

  1. Add a calibration phase before execution

Before a goal becomes an active execution target, Codex could have an explicit calibration mode similar to LLR's INC mode.

In this phase, Codex would:

  • explore the repo, task context, and domain
  • clarify the user's real objective
  • infer hidden requirements
  • surface assumptions and risks
  • discover current expert framing when the domain matters
  • propose hard acceptance criteria
  • ask the user to confirm the contract before execution

This is useful because users often cannot describe the correct goal until Codex has helped explore the space.

  1. Track current effective evidence

A goal could maintain lightweight current evidence, not just checkpoints.

Possible fields could include:

  • user signals
  • verified facts
  • assumptions
  • risks
  • open decisions
  • next action
  • completion signal

The important distinction is:

  • checkpoint = what happened
  • evidence chain = what still matters and why it should guide the next action

LLR's evidence-chain design has been useful because long-running tasks often produce many artifacts, but later review needs to know which facts still support the mainline and which earlier assumptions were overturned.

  1. Add side-thread tolerance

During an active goal, users often remember missing constraints or ask urgent side questions.

A goal workflow could help Codex distinguish whether the latest user message is:

  • a side question
  • a missing constraint
  • a blocker
  • a contract change
  • a stop request
  • a return-to-calibration request

For normal side questions, Codex should answer the user first, then resume the active goal if the main contract is unchanged.

This is one of the most useful parts of LLR in practice: the mainline keeps a compass even when the conversation temporarily walks onto a side path.

  1. Add a premature-stop check

If Codex is about to stop while a goal is active, it could re-evaluate:

  • Is the objective complete?
  • Is the work blocked?
  • Did the user ask to stop?
  • Has the contract changed enough to require recalibration?
  • Is there still a clear next action covered by the goal?

If the next action is clear and still covered by the active goal, Codex should continue instead of asking the user to type "continue".

This is the motivation behind LLR's hook-based stop guard. It is not meant to make Codex run forever. It is meant to prevent the common pattern where Codex states the next step itself, but still stops and waits for the user to approve continuation.

  1. Encourage exploration before validation

In research-heavy or fast-moving domains, Codex search can sometimes behave like answer validation: it searches for high-confidence concepts it already knows instead of discovering the domain from task-level keywords.

LLR's INC guidance asks Codex to derive discovery keywords from the user's wording, project vocabulary, file names, data labels, metrics, failure symptoms, tools, quality bar, and ecosystem terms before presenting expert defaults.

This could also be useful around /goal, especially when a goal depends on current practice, benchmarks, standards, libraries, or domain conventions.

Expected outcome

I would love to know whether the Codex team sees these LLR patterns as:

  • behaviors that could eventually belong inside /goal
  • behaviors better handled by skills/plugins
  • extension points that /goal could expose
  • or simply a userland experiment that should remain outside core Codex

Thanks for adding persisted /goal workflows. LLR is my attempt to explore the surrounding harness that makes long-running goals easier to define, steer, review, and complete.

Additional information

No response

Activity

  1. huahuadeliaoliao
    added
    enhancementNew feature or request
    on May 4, 2026
  2. github-actions
    added
    CLIIssues related to the Codex CLI
    planIssues involving plan mode
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    skillsIssues related to skills
    on May 4, 2026

  3. github-actions commented on May 4, 2026

    @github-actions
    github-actionsBot
    on May 4, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  4. etraut-openai
    removed
    CLIIssues related to the Codex CLI
    skillsIssues related to skills
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    planIssues involving plan mode
    on May 4, 2026

  5. etraut-openai commented on May 4, 2026

    @etraut-openai
    etraut-openai
    on May 4, 2026
    Contributor

    Thanks for the thoughtful feedback.

    We want to make sure that the core primitives that we provide within the Codex harness are generalizable and flexible enough to support many different use cases and workflows. Many of the features and capabilities that you mention here seem like they could be built upon the existing /goal primitive. Which capabilities (if any) do you think are missing from the current core primitive?

  6. safal207 commented on Jun 26, 2026

    @safal207
    safal207
    on Jun 26, 2026 – with ChatGPT Codex Connector

    I think one missing core primitive is phase-aware, congruence-gated continuation.

    A durable /goal should not continue merely because another turn is possible. It should continue only when the previous iteration produced enough evidence to justify a concrete next action.

    A minimal phase model could be:

    CALIBRATE
→ EXPAND
→ COMMIT
→ EXECUTE
→ VERIFY
→ REFLECT
→ CONTINUE | RECALIBRATE | CLOSE | ESCALATE

    The load-bearing transition is EXPAND → COMMIT.

    Expansion may discover possibilities, risks, assumptions, and evidence. But continuation should require a committed step with:

    • a concrete action;
    • the evidence or assumption supporting it;
    • an expected observable result;
    • a verification method;
    • a reconsideration or stop condition.

    Without that transition, long-running agents tend toward either premature closure or repeated compression without progress: summarizing, replanning, searching, or emitting synthetic continuation prompts while external state does not materially change.

    Congruence as the continuation gate

    Before executing a significant next step, the goal runtime could evaluate whether the action is congruent across several dimensions:

    • goal alignment — does it advance the confirmed contract?
    • evidence alignment — is it supported by current verified facts rather than stale assumptions?
    • system alignment — does it improve a local result without damaging architecture, safety, compatibility, or another active workstream?
    • temporal alignment — is this the right action now, with prerequisites satisfied?
    • consequence alignment — are the effects observable, bounded, and reversible where necessary?

    This is not proof that the whole path is correct. It is permission to take the next step. Reality still validates the path through tests, measurements, and observed outcomes.

    Self-observation and integrity preservation

    A long-running agent also needs a lightweight external-observer state: not another worker, but a meta-level record of how the loop is behaving.

    For example:

    observer:
  current_phase: verify
  repeated_pattern: "third retry with unchanged hypothesis"
  unresolved_dissonance:
    - "local tests pass but backward compatibility is unverified"
  progress_signal: local
  dominant_driver: evidence | urgency | habit | recovery

    This observer should not merely judge success or failure. It should detect when the system is looping, defending an old plan, hiding uncertainty, or converting urgency into synthetic progress.

    I would also propose an integrity-preservation invariant: a goal should not achieve a local objective by degrading its own ability to continue safely and truthfully. For an agent, this means preserving state integrity, recovery capacity, safety constraints, and the ability to surface uncertainty rather than fabricating replacement context.

    Loops amplify or attenuate forces

    A loop is not neutral. Each iteration strengthens some dynamics and weakens others.

    Useful runtime questions are:

    • What did this iteration amplify?
    • What did it attenuate?
    • Did it increase verified understanding, mastery, and system coherence?
    • Did it also amplify uncertainty, urgency, repeated error, or irreversible risk?

    A compact state could look like:

    force_delta:
  amplify:
    - verified_knowledge
    - implementation_reliability
    - system_coherence
  attenuate:
    - uncertainty
    - repeated_error
  protect:
    - safety
    - state_integrity
    - recovery_capacity

    The continuation guard could then ask:

    1. What changed in code, evidence, tests, or the effective goal model?
    2. Is there a concrete next action still covered by the contract?
    3. Is it materially different from the previous failed attempt?
    4. Can its result be observed and verified?
    5. Is it congruent with the goal, evidence, wider system, timing, and consequences?
    6. Which forces will another iteration amplify or reduce?
    7. Is continuation serving the goal, or merely avoiding recalibration or closure?

    This does not require embedding a particular philosophy into /goal. The core could expose only general primitives: phase, committed_step, observer_state, force_delta, unresolved_dissonance, and transition_reason. Skills and plugins could then implement different loop strategies on top.

    The key principle is:

    An autonomous loop should not continue because it can. It should continue because the previous turn produced a reality-based, congruent next step while preserving the integrity of the system performing it.

  7. safal207 commented on Jun 26, 2026

    @safal207
    safal207
    on Jun 26, 2026 – with ChatGPT Codex Connector

    One additional refinement: goal phase should be temporal, not only logical.

    The previous comment treats phase as the current position in the work loop. But long-running goals also cross time boundaries: process exit, quota reset, compaction, resume, stale evidence, changed repository state, or changed permissions.

    That suggests separating three clocks:

    temporal_state:
  memory_freshness: current | stale | unknown
  evidence_validity: valid | revalidation_required | invalid
  action_authority: authorized | expired | blocked

    These values should not be inferred from one another.

    • A memory may still be durable while the evidence it contains is stale.
    • Evidence may remain true while the authority to act has expired.
    • A goal may still be active while the previously committed step is no longer congruent with the current system state.

    So resume should not mean "continue from the last sentence." It should mean:

    RESTORE MEMORY
→ REVALIDATE EVIDENCE
→ RECOMPUTE CONGRUENCE
→ RENEW ACTION AUTHORITY
→ CONTINUE OR RECALIBRATE

    A minimal phase record could therefore include:

    phase:
  logical: verify
  entered_at: ...
  last_validated_at: ...
  validity_horizon: ...
  resume_policy: continue | revalidate | recalibrate | block

    This is closely related to lifecycle discussions around external memory and compaction boundaries in Claude Code: anthropics/claude-code#47023

    The general principle is:

    Persisted state is not automatically actionable state. Time can preserve memory while invalidating evidence, congruence, or authority.

    For /goal, that means every significant temporal boundary should be able to trigger a phase re-entry check rather than silently inheriting the previous continuation decision.

  8. hyperbetteri commented on Sep 1, 2026

    @hyperbetteri
    hyperbetteri
    on Sep 1, 2026 – with ChatGPT Codex Connector

    Public-safe prompt pattern: Task-Mode Contract

    Author: Almási Andor Aladár

    For long-running /goal work, intent calibration should include explicit operation-mode separation before execution.

    Suggested compact contract:

    1. Identify the requested mode: ANALYZE, EDIT, TRANSLATE, REGENERATE, SEARCH, or EXECUTE.
    2. Record the objective, excluded scope, required evidence, and completion criteria.
    3. Do not silently escalate from analysis/search/review into mutation.
    4. If the user asks for a partial correction, do not regenerate unrelated material unless necessary.
    5. Treat the latest explicit user override as a contract update; reconcile it before the next tool action.
    6. If a consequential scope/mode change is ambiguous, stop and ask one concise clarification.

    This is deliberately a small public-safe interaction pattern, not a publication of any larger state machine, orchestration framework, or validator.

    Copyright © 2026 Almási Andor Aladár.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions