issues create: --team silently falls back to default team when key/name doesn't resolve

[ryanrozich]

Description

The --team option on issues create accepts a team key or name per the help text (team key, name, or ID), but when a key or name is provided, it silently falls back to the default team instead of resolving correctly or raising an error. Only raw UUIDs work.

This is distinct from #47 (assignee) because the failure mode is silent — no error is raised. The issue is created in the wrong team with no indication anything went wrong.

Steps to Reproduce

Given two teams:

• ADVA (key: ADV, UUID: 06441021-...)
• evergreen (key: EVR, UUID: 5f5b365b-...) — the default team

# Try with team key
linearis issues create "Test ticket" --team ADV
# → Created as EVR-X (wrong team, no error)

# Try with team name
linearis issues create "Test ticket" --team ADVA
# → Created as EVR-X (wrong team, no error)

# Try with UUID (only thing that works)
linearis issues create "Test ticket" --team "06441021-9818-4036-9b48-b6ea6a208871"
# → Created as ADV-X (correct)

Expected Behavior

Either:

1. The team key/name is resolved to a UUID and the issue is created in the correct team, OR
2. An error is raised indicating the team could not be resolved

Actual Behavior

The issue is silently created in the default team (evergreen/EVR) with no error or warning. This is particularly dangerous because the user has no indication the --team flag was ignored.

Test Results

--team value	Result	Expected
ADV (key)	EVR (wrong, silent)	ADV
ADVA (name)	EVR (wrong, silent)	ADV
06441021-... (UUID)	ADV (correct)	ADV

Additional Context

• Issue issues create / issues update with --assignee fails when passing a name instead of UUID #47 documents a similar resolver gap for --assignee, but that case produces an explicit error. This --team case is worse because it's silent.
• The --help text explicitly states the flag accepts "team key, name, or ID", so the resolver is expected to handle all three.

Environment

• linearis version: 2025.12.3 (installed via npm, running version 2025.11.2)
• OS: macOS (Darwin 25.3.0)
• Runtime: Bun 1.1+

[iamfj]

Hi @ryanrozich — first off, thank you for reporting this so clearly and thoroughly.

Issues like this are exactly why community feedback matters so much to us, especially when the failure mode is silent and can lead to work ending up in the wrong place. We really appreciate the time you took to document the behavior, expected outcome, reproduction steps, and context.

Also: sorry that it took us this long to come back to this one.

We genuinely care about our community and want to honor the effort people put into reporting problems like this. Clear reports like yours help make Linearis better for everyone.

After reviewing the current codebase, I believe this issue is likely already addressed.

What changed

In the current implementation, issues create --team now resolves the provided team value through an explicit team resolver before the create mutation is sent. That means:

• a team UUID is passed through directly
• a team key is resolved explicitly
• a team name is resolved explicitly
• and if resolution fails, it now errors instead of silently falling back

This behavior appears to have landed as part of the architecture rewrite in:

• PR feat!: complete architecture redesign with GraphQL codegen, auth system, and developer tooling #45

and was included in the main release line starting with:

• https://github.com/linearis-oss/linearis/releases/tag/v2026.4.1

(That release was promoted to main via PR #49)

Examples

The following should now work as expected:

linearis issues create "Test ticket" --team ADV

linearis issues create "Test ticket" --team ADVA

linearis issues create "Test ticket" --team "06441021-9818-4036-9b48-b6ea6a208871"

And if the team cannot be resolved, it should now fail rather than create the issue in the default team:

linearis issues create "Test ticket" --team DOES_NOT_EXIST

One note

I’m saying “likely addressed” deliberately because I confirmed this by tracing the current code path, not yet by reproducing your exact scenario against a live workspace with the older/newer versions side by side.

If you’re able to test on v2026.4.1+ (or the current latest release), I’d really appreciate a quick confirmation from your side as well. If it still reproduces, I definitely want to keep this open and dig deeper.

Thanks again for the report and for helping improve Linearis.