Skip to content

[Bug]: fw upgrade from a consumer refuses its own shallow auto-clone; the remedy names a directory deleted on exit #87

Open
Open
[Bug]: fw upgrade from a consumer refuses its own shallow auto-clone; the remedy names a directory deleted on exit#87
Labels
area:upgradefw upgrade / vendoringbugSomething isn't workingseverity:highData loss, lost work, security, or blocks a core pathstatus:releasedReleasedtriagedClassified by the AEF intake pipeline

Description

@MikeEchoVoid
MikeEchoVoid
opened on Oct 7, 2026

Bug Description

fw upgrade run inside a vendored consumer project cannot succeed once upstream has moved past the consumer's recorded version_sha. Two parts of lib/upgrade.sh contradict each other:

  • The bare-from-consumer path always clones upstream with git clone --depth=1 (line 1313).
  • The origin guard then looks for the consumer's version_sha in that clone, cannot see it because the history is truncated, and refuses with foreign-source.

The remedy it prints, git -C /tmp/fw-upstream-XXXXXX/fw fetch --unshallow, then re-run fw upgrade, cannot be applied: that directory is removed when the process exits (trap "rm -rf '$_tmpd'" EXIT INT TERM HUP, line 1302), and re-running fw upgrade makes a new shallow clone in a new directory. The only path the message leaves open is the FW_ALLOW_FOREIGN_SOURCE=1 bypass.

The guard can pass only when the consumer is already at the tip, that is, when there is nothing to upgrade.

Steps to Reproduce

  1. Take a vendored consumer project whose .framework.yaml records a version_sha older than upstream master (here: 1.8.3, 542623a, with upstream at 1.8.6).
  2. Run fw upgrade in it.

Observed twice on the same day, once by the agent and once by the operator from his own terminal.

Expected Behavior

fw upgrade fetches enough history to verify the consumer's commit and upgrades the project. If it must refuse, the remedy it prints can actually be followed.

Actual Behavior

Bare-from-consumer detected — auto-cloning upstream
Cloning... ok
Handing off to upstream's bin/fw: upgrade

Framework: /tmp/fw-upstream-XXXXXX/fw (v1.8.6)
Pinned: v1.8.3 (source does not contain this consumer's commit — upgrade will refuse)

REFUSED Consumer v1.8.3 vs framework v1.8.6: foreign-source.
consumer recorded version_sha 542623a, which this SHALLOW clone (/tmp/fw-upstream-XXXXXX/fw) cannot see — its history is truncated, so origin is unverified, not disproved. Run: git -C /tmp/fw-upstream-XXXXXX/fw fetch --unshallow (or clone without --depth), then retry.
Remedy: git -C /tmp/fw-upstream-XXXXXX/fw fetch --unshallow, then re-run fw upgrade.
To proceed anyway: FW_ALLOW_FOREIGN_SOURCE=1 (logged Tier-2).

Exit code 1, nothing modified in the project. /tmp/fw-upstream-XXXXXX no longer exists when the message is read.

fw doctor output



AI Agent


Claude Code


Operating System


Linux


Additional Context


Version: consumer on 1.8.3 (542623a), upstream 1.8.6 (1ea1044). Line numbers are those of lib/upgrade.sh in 1.8.6.


Workaround that worked, without the bypass: a full clone made by hand, then the same hand-off the framework does itself:


git clone <upstream url> <dir>
env FRAMEWORK_ROOT=<dir> PROJECT_ROOT=<project> <dir>/bin/fw upgrade <project>



"28 change(s) applied", version 1.8.6. Without the two variables the cloned bin/fw resolves back to the project's vendored copy and starts the shallow auto-clone again.


Related remark: fw upgrade --dry-run from the consumer stops before cloning and prints only "would clone" and "would re-invoke" (line 1306). It lists none of the changes, so it cannot be used to preview an upgrade.


Suggestions:


    

  1. In the auto-clone path, fetch enough history for the guard: clone without --depth, or deepen the clone when the recorded version_sha is not found, before handing off.
    2. 

  2. Do not print a remedy that names a directory the same process deletes on exit.
    3. 

  3. Let --dry-run clone to the temporary directory so that it can list the changes.
    4. 

Activity
  1. MikeEchoVoid
    added 
    bugSomething isn't working
     on Oct 7, 2026
  2. DimitriGeelen commented on Oct 10, 2026 
    @DimitriGeelen
    DimitriGeelen
    on Oct 10, 2026
    Owner
    [AEF intake] Received — 2026-10-10
    

    Thank you. This issue has been ingested into the Agentic Engineering Framework's intake as INTAKE-0003. Next step: classification (type, affected area, severity, whether it reproduces on the current release and on bleeding-edge). You will get a comment here at each step: classified → decision → in progress → fixed on bleeding-edge → available for testing → released.
    

    These status updates are automated, but Dimitri personally looks at every issue and decides what happens to it. Replies on this issue are read.
  3. DimitriGeelen commented on Oct 10, 2026 
    @DimitriGeelen
    DimitriGeelen
    on Oct 10, 2026
    Owner
    [AEF intake] Classified — 2026-10-10
    

      

    • Type: bug
      • 

    • Area: fw upgrade run from a consumer (shallow auto-clone)
      • 

    • Severity: high
      • 

    • Status: confirmed from the source as still present in the current release (v1.8.8) and on bleeding-edge
      • 

    

    [AEF intake] Accepted — 2026-10-10
    

    Tracked as T-3886 (an existing task already covers this root cause; also reported by two other projects), prioritised (horizon: now). Next update here: in progress.
    

    These status updates are automated, but Dimitri personally looks at every issue and decides what happens to it. Replies on this issue are read.
  4. DimitriGeelen
    added 
    triagedClassified by the AEF intake pipeline
     
    status:acceptedAccepted; linked to an AEF task
     
    severity:highData loss, lost work, security, or blocks a core path
     
    area:upgradefw upgrade / vendoring
     on Oct 10, 2026
  5. DimitriGeelen commented on Oct 11, 2026 
    @DimitriGeelen
    DimitriGeelen
    on Oct 11, 2026
    Owner
    [AEF intake] In progress — 2026-10-11
    

    Work has started under T-3886. Approach: the auto-clone that fw upgrade makes from inside a consumer will keep full commit history (a blobless clone instead of --depth=1), so the origin guard can find your recorded version; and when the guard does refuse an auto-clone, the remedy will be runnable instead of pointing at the deleted temp clone. Next update here: fixed on bleeding-edge.
    

    These status updates are automated, but Dimitri personally looks at every issue and decides what happens to it. Replies on this issue are read.
  6. DimitriGeelen
    added 3 commits that reference this issue on Oct 11, 2026
    T-3886: real ACs for GitHub #87 (full-history auto-clone, runnable re…
    7dc05b2
    T-3886: #87 In progress posted (intake ledger)
    558d843
    T-3886: bare fw upgrade from a consumer auto-clones with full commit …
    e8b6d83
  7. DimitriGeelen commented on Oct 11, 2026 
    @DimitriGeelen
    DimitriGeelen
    on Oct 11, 2026
    Owner
    [AEF intake] Fixed on bleeding-edge — 2026-10-11
    

    Fixed under T-3886 in commit e8b6d83 (on the bleeding-edge branch; not yet in a release).
    

      

    • Bare fw upgrade run from inside a consumer now auto-clones the framework with full commit history (--filter=blob:none instead of --depth=1), so a consumer that is simply behind upstream is no longer refused as foreign-source.
      • 

    • If the guard still refuses (the source itself is shallow), the remedy names a runnable command — clone the framework yourself and run <clone>/bin/fw upgrade <consumer> — instead of the deleted temporary clone.
      • 

    • Regression test tests/unit/t3886_upgrade_autoclone_history.bats fails on the old code and passes on the fix; the fresh-machine upgrade simulations stay green.
      • 

    

    To test it before the release: git clone -b bleeding-edge https://github.com/DimitriGeelen/agentic-engineering-framework.git aef-be && aef-be/bin/fw upgrade /path/to/your/project. Feedback here is welcome. Next update here: released.
    

    These status updates are automated, but Dimitri personally looks at every issue and decides what happens to it. Replies on this issue are read.
  8. DimitriGeelen
    added a commit that references this issue on Oct 11, 2026
    T-4039: #86/#87 Fixed-on-bleeding-edge posted (intake ledger); file T…
    41a7d70
  9. DimitriGeelen commented on Oct 18, 2026 
    @DimitriGeelen
    DimitriGeelen
    on Oct 18, 2026
    Owner
    

    [AEF intake] Released — 2026-10-18
    

    T-3886 is released in v1.8.11.
    

    Please confirm it fixes this for you. Reply here if it does not. With no reply in 14 days this issue is closed with a note, and you can reopen it.
    

    How it was tested: tests/unit/t3886_upgrade_autoclone_history.bats (3 tests: multi-commit fixture; bare consumer upgrade auto-clones with history and is not refused; a shallow refusal never names the temp dir). Green on bleeding-edge.
    
Why it is released now: v1.8.11 passed the full-suite comparison (https://github.com/DimitriGeelen/agentic-engineering-framework/blob/50fae848ff46e156c1be630e85b0644aa070be38/docs/reports/T-4246-full-suite-comparison.md) and the operator's release decision.
    
Field evidence: two v1.8.10 consumers upgraded successfully (1023, 832) by the full-clone route, which works around the bug. The bare auto-clone path itself was not run in the field. Please confirm this works for you.
    
If you are still on v1.8.10: use the full clone route in the upgrade notes, "Upgrading from v1.8.10": https://github.com/DimitriGeelen/agentic-engineering-framework/blob/50fae848ff46e156c1be630e85b0644aa070be38/docs/releases/v1.8.11-upgrade-notes.md#upgrading-from-v1810-use-a-full-clone-not-a-bare-fw-upgrade
    
Release: https://github.com/DimitriGeelen/agentic-engineering-framework/releases/tag/v1.8.11 · Field report: https://github.com/DimitriGeelen/agentic-engineering-framework/blob/50fae848ff46e156c1be630e85b0644aa070be38/docs/reports/field-test-v1.8.11-results.md
    

    These status updates are automated, but Dimitri personally looks at every issue and decides what happens to it. Replies on this issue are read.
  10. DimitriGeelen
    added 
    status:releasedReleased
     and removed 
    status:acceptedAccepted; linked to an AEF task
     on Oct 18, 2026
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
    area:upgradefw upgrade / vendoringbugSomething isn't workingseverity:highData loss, lost work, security, or blocks a core pathstatus:releasedReleasedtriagedClassified by the AEF intake pipeline
    Projects
    No projects
      Milestone
      No milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions