[cchu-ld]

Humans:

• Looks like a big PR - but only 600 lines of actual code change, the rest are tests. There are a lot of tests to test each branching behavior.
• Summary: Implements the flow for selecting agent space.
• Please review this flow chart - does the behavior match what we want?

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

None.

Describe the solution you've provided

• Problem: If the account already had agent spaces, setup reused the space named launchdarkly or created a new one. Users usually have spaces already, and setup did not let them pick one.
  • Solution: If the region has agent spaces, setup lists them and asks which one to use. The list marks the spaces that setup made. --agent-space-id picks a space without the list. --new-agent-space provisions another space. You cannot pass both.
• Problem: The full setup changes the IAM roles, the account association, and the operator app. On a space that another person set up, that can break their configuration.
  • Solution: A space that setup made gets the full setup. Another space gets only the MCP server, unless you pass --auth-flow. A space counts as made by setup only if it has the ldcli:managed tag.
• Problem: --agent-space-name had the default launchdarkly, so a new space got that name without a question.
  • Solution: --agent-space-name has no default. With a name, Enter at the list picks the space with that name, or a new space with that name. Without a name, the list has no default, and a new space makes setup ask for a name. If a space already uses the name, setup asks again.
• Problem: A CI run must work the same on the first run and on every later run.
  • Solution: An unattended run with --agent-space-name X uses X, or provisions X if no space has that name. Without a name, it reuses the one space that setup made, or stops.
• Problem: setup changed AWS with no warning.
  • Solution: setup shows the plan before the first write to AWS. In a terminal, it asks Continue? [y/N]. The new --yes flag skips every question.
• Problem: A person who runs setup --output json in a terminal must also see the question before AWS changes.
  • Solution: setup asks whenever stdin is a terminal, unless you pass --yes. The questions go to stderr, so stdout still has only the JSON. A run without a terminal, such as CI, does not ask.
• Problem: setup asked for a token after it changed AWS. If LaunchDarkly rejected the pasted token, the roles, the space, the association, and the operator app had already changed.
  • Solution: setup asks for the token before it shows the plan, and checks it with LaunchDarkly. If LaunchDarkly rejects it, setup stops before any AWS write. If you press Enter, setup skips the MCP server and says at the end how to connect it.
• Problem: The plan was built before the token prompt, so the plan that the user confirmed still said Ask for a token. After Enter on a connect run, the plan said that setup would register the server, but the run changed nothing.
  • Solution: With a pasted token, setup builds the plan again, so the plan is current. After Enter, the plan says that setup skips the MCP server. A connect run then has nothing to do, so setup stops before the question.
• Problem: A json run showed no progress, and the plan named default credentials when AWS_DEFAULT_PROFILE chose the profile.
  • Solution: Progress goes to stderr in every run. The plan names the profile with SelectedProfile, the same rule as the SDK.
• Problem: A run that failed after it created a space did not name that space, so a failed CI run did not say what it made.
  • Solution: The error names the new space and its ID, and says to run setup again with --agent-space-id <id>. A run with the same --new-agent-space flags stops on the name, so the ID is the safe way back.
• Problem: --new-agent-space read the tags of every space, but it needs only their names. If every tag read failed, it stopped a run that only creates a space.
  • Solution: With --new-agent-space, setup lists the spaces without their tags.
• Problem: If an MCP server appeared between the first plan and the plan after a pasted token, the second plan reused it and did not use the token, with no note.
  • Solution: setup says that it reuses the server that is now registered, and how to replace its token.
• Problem: If setup could not read the tags of one space, the whole run stopped, so one space hid every other space.
  • Solution: The list leaves out a space whose tags setup cannot read, because its owner is unknown. A note names that space and says to pass --agent-space-id <id>. The name checks still count the space, so setup does not offer a new space with its name. If setup cannot read the tags of any space, it stops. A run that cannot ask also stops without --agent-space-name, or if a hidden space has that name.
• Problem: The list note said to pass --agent-space-id for a hidden space, but --agent-space-id also stopped if it could not read the tags. A typo in --agent-space-id gave only the raw AWS error.
  • Solution: On a space whose tags setup cannot read, --agent-space-id only connects the MCP server and says why, unless you pass --auth-flow. On a space that does not exist, the error says to check --region and --profile, or to run setup without the flag to list the spaces.
• Problem: --auth-flow on a space that setup did not make can change a sign-in that someone else set up, and a wrong --agent-space-id was easy to miss.
  • Solution: setup prints a warning before the plan, and the plan line names the current sign-in next to the new one.
• Problem: Without a name, a run that cannot ask reused the one space that setup made, but Enter at the list picked nothing.
  • Solution: Enter now picks that space too. The error for a new space without a name gives an example: --agent-space-name launchdarkly.
• Problem: --agent-space-id still listed every space. A missing permission on another space could stop the run.
  • Solution: With --agent-space-id, setup reads only that space with AgentSpace.
• Problem: The README named only some of the AWS permissions that setup needs.
  • Solution: The README lists the permissions for setup and for status.
• Problem: The token prompt went to stdout. A json run could not show progress or a plan without breaking the JSON.
  • Solution: The plan, the space list, the prompts, and the progress go to stderr. Stdout has only the result, so a json run shows the plan and keeps valid JSON on stdout.
• Problem: Without a terminal, setup changed AWS and then said at the end that the MCP server was not connected.
  • Solution: If no MCP server is registered and setup cannot ask for a token, it stops before it changes AWS.
• Problem: On a connected space with the operator app off, setup printed an operator app URL that did not work.
  • Solution: setup does not print the URL. It says that the app is off, and that you can turn it on in the AWS console. It does not suggest --auth-flow, because the full setup would change a space that setup did not make.

Behavior change from main: --agent-space-id on a space that setup did not make now only connects the MCP server. On main, it ran the full setup. No release has the command yet.

Describe alternatives you've considered

The description Managed by the LaunchDarkly CLI was the first ownership marker. A user can change or copy it, so setup reads only the ldcli:managed tag.

Additional context

Testing: go test ./... and golangci-lint pass on this branch.

I ran setup against a sandbox AWS account. These cases worked: a new space with a typed name, a new space next to existing spaces, and a second EnableOperatorApp call (IAM to IAM) on a space whose app is on.

Not tested against real AWS:

• A change of sign-in method on an app that is on, for example IAM to IdC.
• Role creation in an account without DevOpsAgentRole-AgentSpace and DevOpsAgentRole-WebappAdmin.

🤖 Generated with Claude Code

---

Note

Overview
aws-devops-agent setup is reworked so existing accounts get an interactive (or flag-driven) agent space choice, a pre-flight plan with optional confirmation, and safer connect vs full provision behavior.

When the region already has agent spaces, setup lists them (marking ldcli:managed spaces), supports --agent-space-id, --new-agent-space, and --agent-space-name (no default name), and uses --yes for non-interactive runs. Spaces not created by ldcli get MCP connect-only unless --auth-flow forces full setup (with warnings). Unreadable tags hide spaces from the list but still affect name/default logic; AgentSpaceNames avoids tag lookups when only checking names.

Before any AWS writes, setup shows a plan on stderr, prompts Continue? [y/N] in a TTY (JSON keeps stdout clean), collects/validates the LaunchDarkly token before the plan when needed, and runs ConnectPlan vs RunPlan accordingly. Operator-app-off connect runs no longer print a bogus URL. README documents the flow, CI behavior, and required IAM permissions.

Extensive new tests cover confirmation, selection, flags, plan output, and unattended paths.

^{Reviewed by Cursor Bugbot for commit b296c42. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 36c0096. Configure here.}

[cchu-ld]

@Andrewjeska, thank! All three are addressed.

1. Breaking change: setup is not in a release yet. It came in feat: Add ldcli aws-devops-agent setup #847 after v3.12.0, and the pending 3.13.0 release PR (chore(main): release 3.13.0 #826) is the first one that includes it. So no released CI run depends on the launchdarkly default. If 3.13.0 ships before this PR, that changes, so I also added a hint to the error: a new agent space needs a name; pass --agent-space-name, for example --agent-space-name launchdarkly (f9895a19).

2. --auth-flow on a space that setup did not make: I took option (a) and added a warning. Setup now prints this before the plan:

   Warning: setup did not make agent space platform (space-2). --auth-flow runs the full setup on it, so setup can change its IAM roles, account association, and operator app sign-in.

3. Bad --agent-space-id: A ResourceNotFoundException now gives no agent space space-typo in us-east-1. Check --region and --profile, or run setup without --agent-space-id to list the agent spaces (f9895a19).

This reply is from Claude.