Using `--name` Without `--resume` No Longer Works As Expected

[wpfleger96]

Describe the bug

The --name flag for goose session and goose run commands is broken. When used without --resume, it incorrectly searches for an existing session instead of creating a new session with the specified name which used to work and has regressed

This seems to have been introduced in #4648, and I touched on this in #4937 but didn't address the core bug 😅

To Reproduce

1. Run: goose session --name test-session
2. Observe error: "No session found with name 'test-session'"

Expected behavior

1. A new session should be created with description field set to "test-session"
2. The session ID should be auto-generated in the format YYYYMMDD_X
3. The user can later resume this session using goose session -r --name test-session

Please provide following information:

• OS & Arch: Darwin (Sequoia 15.6.1) arm64
• Interface: CLI
• Version: unreleased, built off latest main
• Extensions enabled: computercontroller, developer
• Provider & Model: Databricks + Claude Sonnet 4

[DOsinga]

hmm, that's annoying. one of the issues is that if you set the name of a session, the system will still override it, so we need a flag indicating that the user has set it

[wpfleger96]

@DOsinga yeah, it's a little confusing what the relationship between a session's ID, name, and description is supposed to be (and which are supposed to be user-configurable)

in the session DB schema we have:

• id
  • autogenerated as YYYYMMDD_X (X is auto incrementing per-day)
  • the help text for --session-id implies that you can specify custom IDs for new sessions, but this doesn't actually seem like it's user-configurable in the code (always auto generated)
• description
  • Initially defaults to CLI Session, gets updated with LLM-generated value after 3 turns
  • Even if --name did work here, the custom name would get overwritten after 3 turns (as you already mentioned)

Historically you could create custom named sessions with --name, but IIRC that would actually set the session ID to whatever you passed to --name since there is no such "name" field for a session. For example in oncall-buddy, we'd use custom session IDs like YYYYMMDD_HHMMSS_OncallBuddy to denote oncall-buddy vs other Goose sessions. But since the SQLite DB migration session IDs are auto generated which breaks that previous behavior.

I think if we can clarify whether we want a session to have a name, a description, or both, and clarify if either/both should be user-configurable, that would help clear this up

[DOsinga]

ok, let's figure out how we want this to work, damn the torpedoes

My thinking is:

• ids should be auto generated, unique and the user should not be able to set them. like if you import a session, it should get a new id. ids are current _idx but that is just a nice convention. don't count on it
• session's don't have names. previously we kinda pretended that a session name was the file name or sometimes the description. maybe we should just rename description to name and use that, and then add functionality to change the name and set a flag the backend doesn't autoname?

once that is in place, we can go through the command line options and make it work they way is should and provide the right error handling and defaults

[wpfleger96]

ids should be auto generated, unique and the user should not be able to set them

totally agreed

maybe we should just rename description to name and use that, and then add functionality to change the name and set a flag the backend doesn't autoname?

yep this is exactly what I was thinking too, sounds great

like if you import a session, it should get a new id

this is the only thing I wanted to clarify - currently if I start a new session then later resume it, it's the same exact session being used (same ID, etc.). going forward does this mean that resuming a session will actually create a new session (as a copy of the original) with a new ID?