Repository navigation
Conversation
Setup now runs the plan that it showed, one step at a time. Before a step writes to AWS, setup makes sure that AWS still matches the plan. If AWS changed, setup stops with ErrPlanChanged. Setup checks the LaunchDarkly token before any AWS write. If no MCP server is registered and setup cannot ask for a token, it stops before it changes AWS. --yes now skips every question. If the operator app of a reused space is on, setup keeps its sign-in, unless you pass --auth-flow. Setup reads the app state, so it needs aidevops:GetOperatorApp. If AWS sends no operator app URL, setup builds the URL from the space ID. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
9758702 to
941e257
Compare
There was a problem hiding this comment.
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 941e257. Configure here.
| name, trustPolicy, policyARN string, | ||
| action RoleAction, | ||
| logf func(string, ...any), | ||
| ) (string, bool, error) { |
There was a problem hiding this comment.
Stale MCP plan after association wait
Medium Severity
RunPlan re-checks AWS before the first write, then can wait up to two minutes in associateAWSAccount before it registers the MCP server or enables the operator app. Those later steps use the original plan and do not call checkMCP or checkApp again. A server or app that appears during that wait no longer gets reused; setup tries to register anyway or calls EnableOperatorApp and can overwrite sign-in. The previous registerMCPServer path looked up the server at write time, so this is a regression versus the live lookup.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit 941e257. Configure here.


Requirements
Related issues
This PR is part 6 of a stack of 7 PRs for
ldcli aws-devops-agent. It goes on PR 5 of the stack. Review and merge the PRs in order.Describe the solution you've provided
setupruns the plan that it showed, one step at a time: IAM roles, agent space, account association, operator app, and MCP server.setupmakes sure that AWS still matches the plan. If AWS changed,setupstops withErrPlanChanged.setupchecks the LaunchDarkly token before any AWS write. If no MCP server is registered andsetupcannot ask for a token, it stops before it changes AWS. Pass--access-tokenin those runs.--yesskips every question, also theaws sso loginquestion.setupkeeps its sign-in, unless you pass--auth-flow.setupreads the app state, so it needsaidevops:GetOperatorApp.setupbuilds the URL from the space ID.Describe alternatives you've considered
None.
Additional context
Testing:
go test ./...andgolangci-lintpass on this branch.🤖 Generated with Claude Code
Note
Overview
aws-devops-agent setupnow executes the plan it displays instead of re-deriving work at apply time. After planning withPlanSetup, it runsRunPlan(full provision) orConnectPlan(MCP-only on an existing space). Each step re-reads AWS first; if reality diverges from the plan, setup aborts withErrPlanChanged(“Run setup again”) rather than partially applying stale intent.Non-interactive and safety behavior tightens.
--yesskips every prompt (confirmation, agent-space choice,aws sso login), matching unattended runs. With no LaunchDarkly token, setup can reuse an existing MCP registration; if it would need to ask for a token (no TTY, JSON output, or--yes) and none exists, it fails before any AWS write and tells you to pass--access-token. LaunchDarkly tokens are validated before writes when registering or replacing MCP credentials.Operator app handling on reused spaces uses
GetOperatorApp: an enabled app keeps its sign-in unless the user explicitly passed--auth-flow(AuthFlowSet). The printed plan adds account association detail; invalid--mcp-service-idis rejected at plan time.Reviewed by Cursor Bugbot for commit 941e257. Bugbot is set up for automated code reviews on this repo. Configure here.