feat: revamp agentcore status command to show all resources status

[notgitika]

Description

This PR revamps the status command to now factor in all resources.

1. You don't have to have an agent in the project to run status anymore.
2. Show resources agents, memory, credentials, gateways and gateway targets
3. Display resource IDs and ARNs if deployed
4. Differentiate between local, deployed and (deployed, removed but not deployed again to apply changes) for each resource
5. Add status logs in the agentcore/.cli/logs/status/ folder
6. Update agentcore status options. New options are:
   • --type -- Filter by resource type (agent, memory, credential, gateway)
   • --state -- Filter by deployment state (deployed, local-only, pending-removal)
   • --agent -- Show only the named agent (other resource types still shown)
   • --json -- Output full result as JSON

Here is what it looks like:

Log file:

Non-interactive command:

Options:

agentcore status --help

Usage: agentcore status|s [options]

Retrieve details of deployed AgentCore resources.

Options:
  --agent-runtime-id <id>  Look up a specific agent runtime by ID
  --target <name>          Select deployment target
  --type <type>            Filter by resource type (agent, memory, credential, gateway)
  --state <state>          Filter by deployment state (deployed, local-only, pending-removal)
  --agent <name>           Filter to a specific agent
  --json                   Output as JSON
  -h, --help               Display help

Run without flags for interactive mode. Flags marked [non-interactive] trigger CLI mode.
Run `agentcore help modes` for details.

Related Issue

Closes #473

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• Manually tested with different scenarios
• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[notgitika]

/strands review

[notgitika]

/strands review

[github-actions]

Code Review Summary

I've completed my review of this PR. Overall, this is a well-implemented feature that significantly improves the agentcore status command. The changes are well-structured, thoroughly tested, and address all requirements from issue #473.

✅ Strengths

1. Excellent test coverage - 303 lines of comprehensive unit tests covering all deployment states and resource types
2. Clean architecture - Good separation between action logic, command registration, and UI components
3. Follows project conventions - Uses ExecLogger for logging, consistent error handling patterns, proper TypeScript typing
4. Addresses all requirements - No longer requires agents, shows all resource types, displays deployment states, tracks pending removals
5. Good UX - New filtering options (--type, --state, --agent, --json) provide flexibility
6. Backward compatible - Existing status functionality still works

💡 Suggestions

suggestion: Add JSDoc to diffResourceSet function

File: src/cli/commands/status/action.ts (lines 72-111)

The diffResourceSet function is clever and generic, but would benefit from documentation explaining the algorithm:

/**
 * Compares local and deployed resource sets to compute deployment states.
 * 
 * Algorithm:
 * 1. For each local resource: mark as 'deployed' if in deployedRecord, else 'local-only'
 * 2. For each deployed resource not in local set: mark as 'pending-removal'
 * 
 * @returns Array of ResourceStatusEntry with computed deployment states
 */
function diffResourceSet<TLocal extends { name: string }, TDeployed>({ ... })

suggestion: Extract validation logic to action layer

File: src/cli/commands/status/command.tsx (lines 58-75)

Input validation currently happens in the command layer with direct rendering. Consider moving validation to the action layer for better separation and testability:

// In action.ts
export function validateStatusOptions(options: StatusCliOptions): { valid: boolean; error?: string } {
  if (options.type && !VALID_RESOURCE_TYPES.includes(options.type)) {
    return { valid: false, error: `Invalid resource type '${options.type}'. Valid types: ${VALID_RESOURCE_TYPES.join(', ')}` };
  }
  // ... other validations
  return { valid: true };
}

suggestion: Consider adding integration test

File: New file needed

The PR includes excellent unit tests, but an integration test would help verify the end-to-end flow with real AWS config files. Consider adding:

// integ-tests/status.test.ts
it('should show all resource types with correct deployment states', async () => {
  // Create project with mixed deployed/local resources
  // Run status command
  // Verify output shows correct states
});

suggestion: Make array mutation more explicit

File: src/cli/commands/status/action.ts (line 224-236)

The code mutates the resources array by index during parallel runtime status fetches. While this works, it could be more explicit:

// Instead of: resources[i] = { ...entry, detail: runtimeStatus.status };
// Consider: Track updates in a Map and merge after Promise.all
const updates = new Map<number, Partial<ResourceStatusEntry>>();
await Promise.all(
  resources.map(async (entry, i) => {
    // ... fetch status ...
    updates.set(i, { detail: runtimeStatus.status });
  })
);
// Apply updates
updates.forEach((update, i) => { resources[i] = { ...resources[i], ...update }; });

nit: Consistent color usage

File: src/cli/tui/components/ResourceGraph.tsx

The code imports DEPLOYMENT_STATE_COLORS from theme for consistency, but still uses magic strings like 'green', 'red', 'blue' for icon colors. Consider using theme constants throughout.

🎯 Questions

question: How does pending-removal state persist?

If a resource is removed from agentcore.json, how does the status command know it was previously deployed? I see it reads from deployed-state.json, but what happens after the user runs deploy to remove it? Does the entry get cleaned up from deployed-state.json?

question: Filter behavior with non-existent resources

What happens if a user runs agentcore status --agent nonexistent-agent? Should it show an error or just show empty results with other resource types?

---

Verdict

No blocking issues found. This PR is ready to merge after addressing any of the suggestions the team deems important. Great work! 🚀

[tejaskash]

LGTM 🚢