allow --with-builtin extension on cli resume

[Evanfeenstra]

Summary

Included builtin extension names in the check_missing_extensions_or_exit check, so that you can add --with-builtin to cli call while also including --resume

The problem:

goose run --with-builtin developer --output-format stream-json --name session1 -t "read the readme"
goose run --with-builtin developer --output-format stream-json --name session1 -t "summarize our convo" --resume
results in: "Extension(s) developer from previous session are no longer available. Restore for this session?"

Type of Change

• Feature
• [ x ] Bug fix
• Refactor / Code quality
• Performance improvement
• Documentation
• Tests
• Security fix
• Build / Release
• Other (specify below)

AI Assistance

• [ x ] This PR was created or reviewed with AI assistance

Testing

Yes, I verified this works by running the flow locally from ./target/debug/goose, and the interative cli prompt did not showup

Related Issues

Relates to #ISSUE_ID
Discussion: LINK (if any)

Screenshots/Demos (for UX changes)

Before:

After:

[Copilot]

Pull request overview

This PR fixes a bug where resuming a session with --with-builtin flags would incorrectly prompt the user about missing extensions, even though those extensions are being explicitly provided via CLI arguments. The fix adds a check to skip the "missing extension" warning for extensions that are supplied through the CLI.

Changes:

• Modified check_missing_extensions_or_exit to accept a set of CLI-provided extension names
• Extensions provided via CLI are now excluded from the missing extensions check during session resume

[Copilot]

The variable collects only builtin extensions, but stdio and streamable_http extensions (added via session_config.extensions and session_config.streamable_http_extensions) are parsed and added later (lines 537-589). However, these other extension types don't go through check_missing_extensions_or_exit, so this is actually correct. The variable name cli_extension_names could be misleading though - consider renaming to cli_builtin_names to clarify it only contains builtin extensions.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

[Evanfeenstra]

maybe this is already solved with #6412 .. but still, this should not be an error at all IMO

[blackgirlbytes]

maybe this is already solved with #6412 .. but still, this should not be an erro

I stand corrected from our thread in Discord. only half the problem is resolved with 6412. After looking at your PR, this would solve the problem fully

[lifeizhou-ap]

Hi @Evanfeenstra,

Thank you for raising the issue and your contribution.

I can still reproduce this issue in interactive mode. I found the issue does not only happen to the built-in extensions, it also happens to --with-extension cli arguments. You can expand the condition that you added to include the extensions passed with --with-extensions and --with-streamable-http-extension

However, we may have another option to fix this problem:
I am now curious about why we have check_missing_extensions_or_exit when resuming the session.

• It only checks whether the original saved extensions exist in the goose config file
• the error message Extension(s) {} from previous session are no longer available. Restore for this session? seems confusing. I copied the error message from the original code while fixing in this [PR](https://github.com/block/goose/pull/6412/changes. I should have thought about this in-depth.

The same prompt would also appear when resuming a recipe if the extension is specified in recipe but not in goose config file.

Since we have extension per session now shall we remove it? cc @wpfleger96 @DOsinga

[wpfleger96]

when resuming sessions, my opinion has been that I should always get the same set of extensions that I had in the original session (instead of resuming the session with your default set of extensions from ~/.config/goose/config.yaml) - I originally started working toward this in #4331

the reason why you see Extension(s) {} from previous session are no longer available. Restore for this session? is because of the change I made in #5974 - goose is detecting that the previous session you're resuming was originally started with an ephemeral extension (--with-builtin/--with-extension/etc) and it's asking if you want to reload that ephemeral extension into the resumed session. this aligns with my same opinion: when resuming a session you should get the same extensions that were in the original session, NOT your default set of extensions in ~/.config/goose/config.yaml

I think I'm a little confused on the issue though. if I start a session with --with-builtin developer, then I later resume that session, based on the current code I would expect goose to interactively prompt and ask me if I want to restore the developer extension into my resumed session. are we saying that instead, goose should automatically restore the developer extension into the resumed session instead of prompting the user to confirm?

[lifeizhou-ap]

when resuming sessions, my opinion has been that I should always get the same set of extensions that I had in the original session (instead of resuming the session with your default set of extensions from ~/.config/goose/config.yaml) - I originally started working toward this in #4331

the reason why you see Extension(s) {} from previous session are no longer available. Restore for this session? is because of the change I made in #5974 - goose is detecting that the previous session you're resuming was originally started with an ephemeral extension (--with-builtin/--with-extension/etc) and it's asking if you want to reload that ephemeral extension into the resumed session. this aligns with my same opinion: when resuming a session you should get the same extensions that were in the original session, NOT your default set of extensions in ~/.config/goose/config.yaml

I think I'm a little confused on the issue though. if I start a session with --with-builtin developer, then I later resume that session, based on the current code I would expect goose to interactively prompt and ask me if I want to restore the developer extension into my resumed session. are we saying that instead, goose should automatically restore the developer extension into the resumed session instead of prompting the user to confirm?

Thank you @wpfleger96 for the reply.

The function is checking whether the original saved extensions exist in the goose config file, not the extension in the resume session exists in the original session. Please correct me if I am wrong.

Current steps:

• user runs goose run --with-extension "npx -y @modelcontextprotocol/server-memory" --output-format stream-json --name session1 -t "read the readme", the server-memory is persisted in the session.
• when user runs resume, the function checks whether server-memory exists in the extensions in the goose config. Since users does not have this extension in the config (which is common, same as recipe sessions), it will prompt user to confirm.

[lifeizhou-ap]

Hi @Evanfeenstra

@wpfleger96 and I had a sync chat and we both thought the check_missing_extensions_or_exit is redundant now. I created a fix PR #6759 to remove it and we won't have the user prompt any more.

I have merged #6759 to main branch, would you please check the main branch out to confirm the issue does not occur to you? If it works for you, would you please close this PR? Thank you!

[Evanfeenstra]

Thank you! makes is easier to automate stuff on servers or in CI pipelines. Worked on main for me