AI‑FDE: Container state visibility and optional per‑session workspace

Product Feedback
1

Hi,

When using AI‑FDE concurrently (multiple sessions and/or human+AI on the same repo), shared container/git state can easily lead to conflicting branch switches and uncommitted changes. In practice, you really need to commit/clean the container before switching to another subject, otherwise later work can be affected in surprising ways.

Today I can ask AI‑FDE explicitly to show git status or clean/reset the container, and that works, but it relies on me remembering to do so at the right times. The existing warning on dirty containers is also helpful, but it often arrives “late” (only once I’ve already started new work).

Are there plans to:

  • Expose container/git state more clearly in the AI‑FDE UI (active repo/branch and whether the working tree is clean or dirty), and

  • Provide a simple UX to either reset the container to a known‑good state or launch a dedicated/isolated workspace for a given session or task?

This would make concurrent work with AI‑FDE smoother and reduce the cognitive load of manually managing shared container state via prompts.

Thanks!

1 Like
2

hey, thanks for the feedback. We are working on making this experience better and exploring being able to work on multiple branches for the same repo in parallel. In the meantime, ai-fde does have a container_git_status tool which it can use to get the git status. One thing that may complicate this is the user action which may sometimes show up when trying to use a container. We are also figuring out ways to make ai-fde more autonomous so that ai-fde can know what state the container is in without the user having to parse that for ai-fde.
As a follow up, it would be helpful to get more information around when ai-fde is not using the git status tool on its own

3

Thanks for the follow‑up.

In my experience the main friction isn’t calling container_git_status itself, but what happens after AI‑FDE edits files:

  • AI‑FDE edits files, but sometimes stops without running container_sync, leaving the working tree dirty.

  • The stale state only shows up later, when it tries to switch branches or start a new task in the same repo.

In terms of when it’s not using git status on its own, I most often see it when:

  • Continuing work in the same repo across multiple prompts (no re‑check of git status between logical tasks).

  • Starting a new task or session on a repo that still has uncommitted changes from earlier AI‑FDE work.

Concrete improvements that would help:

  • Automatically run container_git_status before starting work in a repo and before switching branches.

  • After a logical unit of work (“implement X”, “refactor Y”), either:

    • automatically run container_sync, or

    • prompt: “I’ve changed A/B/C — should I run container_sync now?”

Anecdotally, I’ve hit this less in the last few days; not sure if that’s due to changes on your side or my being more cautious.

Related but slightly separate, I see a similar pattern with CI vs builds:

  • It will commit, run container_sync, and then launch builds without first running ci_checks and waiting for them to complete.

  • That seems to trigger builds against the latest commit that previously passed checks, not the commit that just changed, so I now explicitly remind it to run ci_checks and wait before building.

  • I also tend to avoid previews it initiates: preview outputs can be very large in terms of token usage, so I often disable that tool. It’s possible this is disrupting the logic chain you expect, but for some parts of my code base preview results simply overflow the session context.