I’ve added a new launch darkly flag to toggle between the new and old
block menu in the builder.
### Changes 🏗️
- A new flag name `NEW_BLOCK_MENU` has been added.
- A new block menu block has been created, which is a normal component.
It will be expanded with more components in the future. Currently, it’s
just a one-line component.
- A new control panel has been created, which improves state
localisation and has a new design according to the design files.
<img width="1512" height="981" alt="Screenshot 2025-08-18 at 2 49 54 PM"
src="https://github.com/user-attachments/assets/3deeefe3-9e42-4178-9cf9-77773ed7e172"
/>
### Checklist 📋
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Everything works perfectly on local.
### Changes 🏗️
- Generate API client for orval v7.11.2
- Fix type error in `useAgentSelectStep.ts`
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Platform works
- [x] Updated codepath in `useAgentSelectStep.ts` works
## Summary
Fixes three critical issues in the admin dashboard spending page
(SECRT-1438):
- Fixed user search not working (P1) - query parameters weren't being
passed to backend
- Fixed broken pagination (P1) - server-side GET requests missing query
parameters
- Added visual feedback for credit updates (P3) - toast notifications,
loading states, auto-dismiss modal
## Root Cause
Server-side API requests weren't appending query parameters for
GET/DELETE requests in the `makeAuthenticatedRequest` function in
`helpers.ts`.
## Changes
- Added missing `transaction_filter` parameter to API client's
`getUsersHistory` method
- Fixed server-side GET request query parameter handling by updating
`makeAuthenticatedRequest` to use `buildUrlWithQuery`
- Added Suspense key to force re-render on URL parameter changes
- Added toast notifications for success/error states when adding credits
- Modal now closes automatically after successful submission
- Added loading state with disabled buttons during credit submission
- Page refreshes automatically to show updated balances
- Added debug logging to help diagnose parameter passing issues
## Test Plan
- [x] Search for users by email in admin spending dashboard
- [x] Navigate through pagination (Next/Previous buttons)
- [x] Filter by transaction type (Grant, Usage, etc.)
- [x] Add credits to a user account
- [x] Verify toast notification appears
- [x] Verify modal closes after successful submission
- [x] Verify balance updates without manual refresh
## Linear Issue
Closes [SECRT-1438](https://linear.app/autogpt/issue/SECRT-1438)
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Changes 🏗️
Not a helpful console log to land in production... We should disallow
console logs all together on the Front-end code, but that is a separate,
bigger PR...
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Go to the signup page
- [x] Play with the password inputs
- [x] Password is not printed in the console
#### For configuration changes:
None
## Summary
This PR adds the frontend service to the Docker Compose configuration,
enabling `docker compose up` to run the complete stack, including the
frontend. It also implements comprehensive environment variable
improvements, unified .env file support, and fixes Docker networking
issues.
## Key Changes
### 🐳 Docker Compose Improvements
- **Added frontend service** to `docker-compose.yml` and
`docker-compose.platform.yml`
- **Production build**: Uses `pnpm build + serve` instead of dev server
for better stability and lower memory usage
- **Service dependencies**: Frontend now waits for backend services
(`rest_server`, `websocket_server`) to be ready
- **YAML anchors**: Implemented DRY configuration to avoid duplicating
environment values
### 📁 Unified .env File Support
- **Frontend .env loading**: Automatically loads `.env` file during
Docker build and runtime
- **Backend .env loading**: Optional `.env` file support with fallback
to sensible defaults in `settings.py`
- **Single source of truth**: All `NEXT_PUBLIC_*` and API keys can be
defined in respective `.env` files
- **Docker integration**: Updated `.dockerignore` to include `.env`
files in build context
- **Git tracking**: Frontend and backend `.env` files are now trackable
(removed from gitignore)
### 🔧 Environment Variable Architecture
- **Dual environment strategy**:
- Server-side code uses Docker service names
(`http://rest_server:8006/api`)
- Client-side code uses localhost URLs (`http://localhost:8006/api`)
- **Comprehensive config**: Added build args and runtime environment
variables
- **Network compatibility**: Fixes connection issues between frontend
and backend containers
- **Shared backend variables**: Common environment variables (service
hosts, auth settings) centralized using YAML anchors
### 🛠️ Code Improvements
- **Centralized env-config helper** (`/frontend/src/lib/env-config.ts`)
with server-side priority
- **Updated all frontend code** to use shared environment helpers
instead of direct `process.env` access
- **Consistent API**: All environment variable access now goes through
helper functions
- **Settings.py improvements**: Better defaults for CORS origins and
optional .env file loading
### 🔗 Files Changed
- `docker-compose.yml` & `docker-compose.platform.yml` - Added frontend
service and shared backend env vars
- `frontend/Dockerfile` - Simplified build process to use .env files
directly
- `backend/settings.py` - Optional .env loading and better defaults
- `frontend/src/lib/env-config.ts` - New centralized environment
configuration
- `.dockerignore` - Allow .env files in build context
- `.gitignore` - Updated to allow frontend/backend .env files
- Multiple frontend files - Updated to use env helpers
- Updates to both auto installer scripts to work with the latest setup!
## Benefits
- ✅ **Single command deployment**: `docker compose up` now runs
everything
- ✅ **Better reliability**: Production build reduces memory usage and
crashes
- ✅ **Network compatibility**: Proper container-to-container
communication
- ✅ **Maintainable config**: Centralized environment variable management
with .env files
- ✅ **Development friendly**: Works in both Docker and local development
- ✅ **API key management**: Easy configuration through .env files for
all services
- ✅ **No more manual env vars**: Frontend and backend automatically load
their respective .env files
## Testing
- ✅ Verified Docker service communication works correctly
- ✅ Frontend responds and serves content properly
- ✅ Environment variables are correctly resolved in both server and
client contexts
- ✅ No connection errors after implementing service dependencies
- ✅ .env file loading works correctly in both build and runtime phases
- ✅ Backend services work with and without .env files present
### Checklist 📋
#### For configuration changes:
- [x] `.env.default` is updated or already compatible with my changes
- [x] `docker-compose.yml` is updated or already compatible with my
changes
- [x] I have included a list of my configuration changes in the PR
description (under **Changes**)
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Lluis Agusti <hi@llu.lu>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Nicholas Tindle <nicholas.tindle@agpt.co>
Co-authored-by: Claude <claude@users.noreply.github.com>
Co-authored-by: Bentlybro <Github@bentlybro.com>
## Changes 🏗️
<img width="800" height="687" alt="Screenshot 2025-08-12 at 15 52 41"
src="https://github.com/user-attachments/assets/0d2d70b8-e727-428b-915e-d4c108ab7245"
/>
<img width="800" height="772" alt="Screenshot 2025-08-12 at 15 52 53"
src="https://github.com/user-attachments/assets/b9790616-3754-455e-b8f6-58cd7f6b5a18"
/>
Update the Account Settings ( `profile/settings` ) form so that:
- it uses the new Design System components
- it is split into 2 forms ( update email & notifications )
- the change password inputs have been removed instead we link to the
`/reset-password` page
- uses a normal API route and client query to update the email
This might fix as well an error we are seeing when updating email
preferences on dev. My guess is it is failing because previously it was
using a server action + supabase and it didn't have access to the
cookies auth 🍪
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Navigate to `/profile/settings`
- [x] Can update the email
- [x] Can change notification preferences
- [x] New E2E tests pass on the CI and make sense
### For configuration changes:
None
## Changes 🏗️
Use a skeleton for the martkeplace loading state, representing visually
how the place should looks. Looks a bit more stylish than the previous
`Loading...` text.
### Before
<img width="800" height="774" alt="Screenshot 2025-08-12 at 16 01 22"
src="https://github.com/user-attachments/assets/29e44a1a-2089-468c-a253-3a6b763ada5a"
/>
### After
<img width="800" height="761" alt="Screenshot 2025-08-12 at 16 01 01"
src="https://github.com/user-attachments/assets/5ad362ae-df1d-4a1b-90ae-9349a81a4d75"
/>
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Martketplace loading state looks good across screen sizes
### For configuration changes:
None
I have added e2e tests for agent dashboard page
It includes, tests like
- dashboard page loads successfully
- submit agent button works correctly
- agent table displays data correctly
- agent table actions work correctly
I’ve also updated the e2e test script to include some static agent
submissions, so I can test if it loads on the frontend.
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] All tests are working perfectly locally
<img width="469" height="177" alt="Screenshot 2025-08-08 at 12 13 42 PM"
src="https://github.com/user-attachments/assets/5e37afc3-c151-476a-84de-0a06f44a0722"
/>
Currently, we’re only seeing the top 20 agents, but we need to display
all of them until we see more call-to-action buttons.
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] All tests are working perfectly
- [x] It's working manually as well
Reverts Significant-Gravitas/AutoGPT#10536 to bring platform back up due
to this error:
```
│ Error creating Supabase client Error: @supabase/ssr: Your project's URL and API key are required to create a Supabase client! │
│ │
│ Check your Supabase project's API settings to find these values │
│ │
│ https://supabase.com/dashboard/project/_/settings/api │
│ at <unknown> (https://supabase.com/dashboard/project/_/settings/api) │
│ at bX (.next/server/chunks/3873.js:6:90688) │
│ at <unknown> (.next/server/chunks/150.js:6:13460) │
│ at n (.next/server/chunks/150.js:6:13419) │
│ at o (.next/server/chunks/150.js:6:14187) │
│ ⨯ Error: Your project's URL and Key are required to create a Supabase client! │
│ │
│ Check your Supabase project's API settings to find these values │
│ │
│ https://supabase.com/dashboard/project/_/settings/api │
│ at <unknown> (https://supabase.com/dashboard/project/_/settings/api) │
│ at bY (.next/server/chunks/3006.js:10:486) │
│ at g (.next/server/app/(platform)/auth/callback/route.js:1:5890) │
│ at async e (.next/server/chunks/9836.js:1:101814) │
│ at async k (.next/server/chunks/9836.js:1:15611) │
│ at async l (.next/server/chunks/9836.js:1:15817) { │
│ digest: '424987633' │
│ } │
│ Error creating Supabase client Error: @supabase/ssr: Your project's URL and API key are required to create a Supabase client! │
│ │
│ Check your Supabase project's API settings to find these values │
│ │
│ https://supabase.com/dashboard/project/_/settings/api │
│ at <unknown> (https://supabase.com/dashboard/project/_/settings/api) │
│ at bX (.next/server/chunks/3873.js:6:90688) │
│ at <unknown> (.next/server/chunks/150.js:6:13460) │
│ at n (.next/server/chunks/150.js:6:13419) │
│ at j (.next/server/chunks/150.js:6:7482) │
│ Error creating Supabase client Error: @supabase/ssr: Your project's URL and API key are required to create a Supabase client! │
│ │
│ Check your Supabase project's API settings to find these values │
│ │
│ https://supabase.com/dashboard/project/_/settings/api │
│ at <unknown> (https://supabase.com/dashboard/project/_/settings/api) │
│ at bX (.next/server/chunks/3873.js:6:90688) │
│ at <unknown> (.next/server/chunks/150.js:6:13460) │
│ at n (.next/server/chunks/150.js:6:13419) │
│ at h (.next/server/chunks/150.js:6:10561) │
│ Error creating Supabase client Error: @supabase/ssr: Your project's URL and API key are required to create a Supabase client! │
│ │
│ Check your Supabase project's API settings to find these values │
│ │
│ https://supabase.com/dashboard/project/_/settings/api │
│ at <unknown> (https://supabase.com/dashboard/project/_/settings/api) │
│ at bX (.next/server/chunks/3873.js:6:90688) │
│ at <unknown> (.next/server/chunks/150.js:6:13460) │
│ at n (.next/server/chunks/150.js:6:13419)
```
## Summary
This PR adds the frontend service to the Docker Compose configuration,
enabling `docker compose up` to run the complete stack including the
frontend. It also implements comprehensive environment variable
improvements and fixes Docker networking issues.
## Key Changes
### 🐳 Docker Compose Improvements
- **Added frontend service** to `docker-compose.yml` and
`docker-compose.platform.yml`
- **Production build**: Uses `pnpm build + serve` instead of dev server
for better stability and lower memory usage
- **Service dependencies**: Frontend now waits for backend services
(`rest_server`, `websocket_server`) to be ready
- **YAML anchors**: Implemented DRY configuration to avoid duplicating
environment values
### 🔧 Environment Variable Architecture
- **Dual environment strategy**:
- Server-side code uses Docker service names
(`http://rest_server:8006/api`)
- Client-side code uses localhost URLs (`http://localhost:8006/api`)
- **Comprehensive config**: Added build args and runtime environment
variables
- **Network compatibility**: Fixes connection issues between frontend
and backend containers
### 🛠️ Code Improvements
- **Centralized env-config helper** (`/frontend/src/lib/env-config.ts`)
with server-side priority
- **Updated all frontend code** to use shared environment helpers
instead of direct `process.env` access
- **Consistent API**: All environment variable access now goes through
helper functions
### 🔗 Files Changed
- `docker-compose.yml` & `docker-compose.platform.yml` - Added frontend
service
- `frontend/Dockerfile` - Added build args for environment variables
- `frontend/src/lib/env-config.ts` - New centralized environment
configuration
- Multiple frontend files - Updated to use env helpers
## Benefits
- ✅ **Single command deployment**: `docker compose up` now runs
everything
- ✅ **Better reliability**: Production build reduces memory usage and
crashes
- ✅ **Network compatibility**: Proper container-to-container
communication
- ✅ **Maintainable config**: Centralized environment variable management
- ✅ **Development friendly**: Works in both Docker and local development
## Testing
- ✅ Verified Docker service communication works correctly
- ✅ Frontend responds and serves content properly
- ✅ Environment variables are correctly resolved in both server and
client contexts
- ✅ No connection errors after implementing service dependencies
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
In this PR, I’ve added library page tests.
### Changes
I’ve added 9 tests: 8 for normal flows and 1 for checking edge cases.
Test names are something like:
- Library navigation is accessible from the navbar.
- The library page loads successfully.
- Agents are visible, and cards work correctly.
- Pagination works correctly.
- Sorting works correctly.
- Searching works correctly.
- Pagination while searching works correctly.
- Uploading an agent works correctly.
- Edge case: Search edge cases and error handling behave correctly.
Other than that, I’ve added a new utility that uses the build page to
help us create users at the start, which we could use to test the
library page.
- All tests are passing locally
<img width="514" height="465" alt="Screenshot 2025-07-12 at 11 13 41 AM"
src="https://github.com/user-attachments/assets/7a46c437-7db5-458b-b99a-4fa0d479866f"
/>
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] All library tests are working locally and on CI perfectly.
Updated login and signup pages to display the Turnstile CAPTCHA and
require verification only when running in a cloud environment. This
prevents unnecessary CAPTCHA prompts in local or non-cloud deployments.
### Changes 🏗️
Locally when you try to login with the wrong password, and you update
and login again, you get a warning about captcha which is wrong, so this
fix makes it so the captcha will only when running in a cloud
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
<!-- Put your test plan here: -->
- [x] Try to login with the wrong password, get "Invalid login
credentials" and try to login again, you should keep getting "Invalid
login credentials" and it should not mention captcha
This PR helps us bypass the proxy server in server-side requests,
allowing us to directly send requests to the backend and reduce latency.
### Changes 🏗️
- Introduced server-side detection to dynamically set the base URL for
API requests.
- Added error handling for server-side requests to log failures and
throw errors appropriately.
- Updated header management to include authentication tokens when
applicable.
### Checklist 📋
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] All E2E tests are working.
- [x] I have manually checked the server-side and client-side
components, and both are working perfectly.
- Resolves -
https://github.com/Significant-Gravitas/AutoGPT/issues/10433
- Depends on -
https://github.com/Significant-Gravitas/AutoGPT/pull/10427
- Need to review this pr, once this issue is fixed -
https://github.com/Significant-Gravitas/AutoGPT/issues/10404
I’ve created additional tests for the agents marketplace page
Tests that I have added
- Add to library button works and agent appears in library.
- Download button functionality works.
- Agent page details are visible.
- User can access agent page when logged in.
- User can access agent page when logged out
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] I have done all the tests and they are working perfectly
---------
Co-authored-by: Nicholas Tindle <nicholas.tindle@agpt.co>
Co-authored-by: Lluis Agusti <hi@llu.lu>
Co-authored-by: Zamil Majdy <zamil.majdy@agpt.co>
Co-authored-by: Ubbe <hi@ubbe.dev>
We currently use infinite scroll pagination in multiple places, but our
strategies vary across these locations. This repetitive code writing is
not ideal, and our current methods are also complex. We’re not utilising
React Query’s useInfiniteQuery hooks effectively.
To address these issues, we’re introducing a new component called
`InfiniteScroll` that handles pagination independently.
### How to use it?
- Use React Query’s `useInfiniteHook` to return multiple data points.
For pagination, we only need `fetchNextPage`, `hasNextPage`, and
`isFetchingNextPage`.
```ts
const {
data: agents,
fetchNextPage,
hasNextPage,
isFetchingNextPage,
isLoading: agentLoading,
} = useGetV2ListLibraryAgentsInfinite(
{
page: 1,
page_size: 8,
search_term: searchTerm || undefined,
sort_by: librarySort,
},
);
```
- Simply pass these three data points and the current data length to the
`InfiniteScroll` component. That's it
```tsx
<InfiniteScroll
dataLength={agents.length}
isFetchingNextPage={isFetchingNextPage}
fetchNextPage={fetchNextPage}
hasNextPage={hasNextPage}
loader={<LoadingSpinner />}
>
...
```
### Changes
- Add the `InfiniteScroll.tsx` component for consistency and simplicity
in pagination across the frontend.
- Update the current library page to use the `InfiniteScroll` component.
### Checklist 📋
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] I’ve tested everything locally, and it’s working perfectly fine.
- Resolves -
https://github.com/Significant-Gravitas/AutoGPT/issues/10428
- Depends on -
https://github.com/Significant-Gravitas/AutoGPT/pull/10427
- Need to review this pr, once this issue is fixed -
https://github.com/Significant-Gravitas/AutoGPT/issues/10404
I’ve created additional tests for the creators marketplace page
Tests that I have added
- User can access creator's page when logged out.
- User can access creator's page when logged in.
- Creator page details are visible.
- Agents in agent by sections navigation works.
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] I have done all the tests and they are working perfectly
With this PR, we’re changing the data fetching strategy on the
marketplace page. We’re now using autogenerated React queries.
### Changes
- Splits separate render logic and hook logic.
- Update the data fetching strategy.
- Currently, we’re seeing agents in the featured section and creators in
the featured creators section, even if they’re not set to “isFeatured”
true. I’ve fixed that also.
### Checklist 📋
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] All marketplace E2E tests are working.
- [x] I’ve tested all the links and checked if everything renders
perfectly on the marketplace page.
## Changes 🏗️
- Moved API call from `usePublishAgentModal` to `useAgentInfoStep` for
better encapsulation
- overall cleaner state management + [state
colocation](https://kentcdodds.com/blog/state-colocation-will-make-your-react-app-faster)
- Added loading states with a spinner to the submit button during API
call
- Removed redundant validation: now relies entirely on zod schema
validation
- All thumbnails now use 16:9 (`aspect-video`) aspect ratio for
consistency
- Highlight selected thumbnails with blue border
- Table alignment fixes
- Rename `Edit` action to `View` to better reflect the content of the
modal that appears when clicked...
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] API calls work with loading states in Agent Info Step
- [x] Image aspect ratios are consistent across all components
- [x] Form validation works through zod schema only
### For configuration changes:
None
## Changes 🏗️
### Why these changes
We have a high-priority bug where the publish agent modal wouldn't open
when clicking `Edit` on the Dashboard Creator page table. The create
form was also buggy.
When looking into the code, I noticed it was pretty messy. I went ahead
and refactored it:
- [x] separation of concerns ( _split render / hook logic_ )
- [x] split into sub-components ( `PublishAgentModal/components` )
- [x] colocated state ( moved state to the modal steps rather than
having everything top-level )
- [x] used the new Design System components
Overall, we end up with a cleaner and stable experience ✨
### E2E tests
I also added E2E tests 🤖 to make sure we catch regressions in the future
in this modal. For now, it tests the first 2 steps. It does not do image
upload and publish as that wasn't working locally ( _might iterate on
that later_ )
### Step 1 – Select Agent
<img width="1161" height="859" alt="Screenshot 2025-07-29 at 16 12 46"
src="https://github.com/user-attachments/assets/a4949fb0-1a44-4926-a374-51eefadef063"
/>
### Step 2 – Agent Info Form
<img width="1061" height="804" alt="Screenshot 2025-07-29 at 16 03 11"
src="https://github.com/user-attachments/assets/b9a45bda-18ea-4844-b52c-db499f45193e"
/>
### Step 3 – Agent Review
<img width="1480" height="867" alt="Screenshot 2025-07-29 at 16 11 07"
src="https://github.com/user-attachments/assets/248bdf58-886d-43f3-a37a-35fd1a83e566"
/>
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] open the modal through the Account menu → ( `Publish Agent` )
- [x] complete the form and check validation errors
- [x] add images and generate image
- [x] publish the agent
- [x] the agent shows up on the table
- [x] Open an agent under review in the table ( _click `Edit` on the
actions_ )
- [x] it opens the modal on the 3rd step ( _review step_ )
### For configuration changes:
None
---------
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Co-authored-by: Abhimanyu Yadav <122007096+Abhi1992002@users.noreply.github.com>
## Changes 🏗️
My previous PR,
https://github.com/Significant-Gravitas/AutoGPT/pull/10480, didn't fully
resolve the issue of broken links sometimes appearing for some runs in
the Agent Activity dropdown.
- Fixed the logic ( verified with a deployment in dev... )
- Simplified logic, making less API calls
- If we have an execution without a clear agent ID, we display it but
don't link to it
- Re-generated API types ( _had to update call in dashboard agents
because of it_ )
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Run agents
- [x] Runs appear correctly in the activity dropdown without broken
links
### For configuration changes:
None
## Changes 🏗️
There is a bug where the agent activity dropdown bubble only shows up to
`6` even if there are `50 running agents`. We only display the last 6
runs in the dropdown, but the bubble badge count should show the correct
all running agents.
On top of that we added the option to search runs by agent name when you
have more than 6 recent runs:
https://github.com/user-attachments/assets/931e3db7-5715-48d1-b4df-22490fae9de0
- Also make the dropdown items a link ( `a` ) so that you can command
click them to open runs in new tabs.
- Keep up to `400` executions on the state ( worse case load test )
- Each execution object is relatively small (ID, status, timestamps,
agent info)
- 400 objects × ~`1KB` each = negligible memory footprint `400kb`
- Always display running agents at the top
- Only display runs from the last week on the dropdown
- the agent library page contains the historical runs, this is just to
show the recent ones
### Code changes
- **Added count tracking**
- the `NotificationState` interface now includes separate count fields
(`activeCount`, `recentCompletionsCount`, `recentFailuresCount`) to
track the actual numbers independent of display limits.
- **Dual array system:**
- the `categorizeExecutions` function now creates:
- unlimited arrays for counting all executions
- limited arrays (sliced to 6 items) for dropdown display
- Updated all helper functions to properly maintain both the display
arrays and the count fields.
- Component uses actual counts
- `<AgentActivityDropdown />` component now uses `activeCount` for the
badge and hover hint instead of `activeExecutions.length`
## Checklist 📋
### For code changes
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Login and navigate to library or build
- [x] Start running agents like there is no tomorrow
- [x] The badge shows the correct agent execution count ( .i.e 10 )
- [x] The dropdown only displays the 6 most recent
- [x] You can command click on the runs and they open in new tabs
### For configuration changes
None
We want scrolling for agent dialog list
- Based on #9833
### Changes 🏗️
- adds backend support for paginating this content
- adds frontend support for scrolling pagination
<!-- Concisely describe all of the changes made in this pull request:
-->
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
<!-- Put your test plan here: -->
- [x] test UI for this
---------
Co-authored-by: Venkat Sai Kedari Nath Gandham <154089422+Kedarinath1502@users.noreply.github.com>
Co-authored-by: Claude <claude@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
## Changes 🏗️
- Close websocket connections gracefully during logout ( _whether from
another tab or not_ )
- Also fixed an error on `HeroSection` that shows when the onboarding is
disabled locally ( `null` )
- Uncomment legit tests about connecting/saving agents
- Centralise local storage usage through a single service with typed
keys
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Login in 3 tabs ( 1 builder, 1 marketplace, 1 agent run view )
- [x] Logout from the marketplace tab
- [x] The other tabs show logout state gracefully without toasts or
errors
- [x] Websocket connections are closed ( _devtools console shows that_ )
### For configuration changes:
None
This PR implements a comprehensive Ayrshare social media integration for
AutoGPT Platform, enabling users to post content across multiple social
media platforms through a unified interface. Ayrshare provides a single
API to manage posts across Facebook, Twitter/X, LinkedIn, Instagram,
YouTube, TikTok, Pinterest, Reddit, Telegram, Google My Business,
Bluesky, Snapchat, and Threads.
The integration addresses the need for social media automation and
content distribution workflows within AutoGPT agents, allowing users to:
- Connect their social media accounts via SSO
- Post content with platform-specific options and constraints
- Schedule posts across multiple platforms simultaneously
- Handle platform-specific media requirements and validation
⚠️ To simplify the review process all except the twitter post block has
been commented out, future pr's will uncomment other platfroms so we can
test them in isolation.
### Changes 🏗️
#### Backend Integration (`backend/integrations/ayrshare.py`)
- **AyrshareClient**: Complete API client implementation with post
creation, profile management, and JWT generation
- **SocialPlatform enum**: Comprehensive platform definitions for all
supported social networks
- **Response models**: PostResponse, ProfileResponse, JWTResponse for
type-safe API interactions
- **Error handling**: Custom AyrshareAPIException with proper HTTP
status code handling
#### Social Media Posting Blocks (`backend/blocks/ayrshare/post.py`)
- **BaseAyrshareInput**: Shared input schema with common fields (post
text, media URLs, scheduling, etc.)
- **Platform-specific blocks**: 13 dedicated posting blocks, each with
platform-specific validation and options:
- PostToFacebookBlock: Carousel, Reels, Stories, targeting, alt text
- PostToXBlock: Threads, polls, long posts, premium features, subtitles
- PostToLinkedInBlock: Document support, visibility controls, audience
targeting
- PostToInstagramBlock: Stories, Reels, user tags, collaborators
- PostToYouTubeBlock: Video uploads, playlists, visibility, country
targeting
- PostToPinterestBlock: Pins, carousels, board management
- PostToTikTokBlock: Video/image posts, AI labeling, brand content
- PostToRedditBlock: Basic posting functionality
- PostToTelegramBlock: GIF handling, mentions
- PostToGMBBlock: Event/offer posts, call-to-action buttons
- PostToBlueskyBlock: Character limit validation, alt text
- PostToSnapchatBlock: Story types, video thumbnails
- PostToThreadsBlock: Hashtag restrictions, carousel support
#### Helper Models
- **CarouselItem**: Facebook carousel configuration
- **CallToAction, EventDetails, OfferDetails**: Google My Business post
types
- **InstagramUserTag**: Instagram user tagging with coordinates
- **LinkedInTargeting**: LinkedIn audience targeting options
- **PinterestCarouselOption**: Pinterest carousel image options
- **YouTubeTargeting**: YouTube country blocking/allowing
#### Authentication & SSO (`backend/server/integrations/router.py`)
- **SSO endpoint**: `/integrations/ayrshare/sso_url` for account linking
- **Profile management**: Automatic profile creation and key management
- **JWT generation**: Secure token generation for social media account
linking
- **Platform allowlist**: Configured access to all supported social
platforms
#### Frontend Integration (`frontend/src/components/CustomNode.tsx`)
- **AYRSHARE block type**: New BlockUIType.AYRSHARE for
Ayrshare-specific nodes
- **SSO button**: "Connect Social Media Accounts" with loading states
- **Handle generation**: Special handling for Ayrshare blocks with SSO
integration
#### Configuration
- **Environment variables**: Added AYRSHARE_API_KEY and AYRSHARE_JWT_KEY
to .env.example
- **Block registration**: All Ayrshare blocks registered in
AYRSHARE_NODE_IDS array
#### Type Safety & Error Handling
- **Modern typing**: Updated to use `list`, `dict`, `Any` instead of
legacy typing
- **Comprehensive validation**: Platform-specific constraints (character
limits, media counts, file types)
- **User-friendly errors**: Clear error messages for validation failures
and API errors
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
**Test Plan:**
**Backend API Testing:**
- [x] Verify AyrshareClient initializes correctly with API key
- [x] Test JWT generation for SSO authentication
- [x] Test profile creation and management
- [x] Verify all 13 posting blocks are properly registered
- [x] Test platform-specific validation rules for each block
- [x] Verify error handling for missing credentials and API failures
**Frontend Integration Testing:**
- [x] Verify AYRSHARE block type renders correctly in flow editor
- [x] Test SSO button functionality and popup window behavior
- [x] Confirm loading states work properly during authentication
- [x] Verify input handles generate correctly for Ayrshare blocks
- [x] Test platform-specific input fields and validation
**End-to-End Workflow Testing:**
- [x] Create agent with Ayrshare posting blocks
- [x] Test SSO flow: click "Connect Social Media Accounts" button
- [x] Verify popup opens with Ayrshare authentication page
- [x] Test social media account linking process
- [x] Create posts with various platform-specific options:
- [ X ] X (Twitter) - tested basic posting with image
- [] Test scheduling functionality across platforms
- [x] Verify media upload constraints and validation
- [] Test error handling for invalid inputs and failed posts
**Error Case Testing:**
- [] Test behavior with missing AYRSHARE_API_KEY configuration
- [] Test invalid social media credentials handling
- [] Test network failure scenarios
- [] Verify platform-specific validation error messages
- [] Test character limit enforcement per platform
- [] Test media file type and size restrictions
**Security Testing:**
- [ x ] Verify JWT tokens are properly generated and validated
- [x] Test profile key isolation between users
- [x] Confirm sensitive credentials are not logged
- [x] Verify SSO popup prevents XSS attacks
#### For configuration changes:
- [x] `.env.example` is updated or already compatible with my changes
- [x] `docker-compose.yml` is updated or already compatible with my
changes
- [x] I have included a list of my configuration changes in the PR
description (under **Changes**)
**Configuration Changes:**
- Added `AYRSHARE_API_KEY` environment variable for Ayrshare API
authentication
- Added `AYRSHARE_JWT_KEY` environment variable for SSO token generation
- No docker-compose.yml changes required (uses existing backend
services)
---------
Co-authored-by: Reinier van der Leer <pwuts@agpt.co>
## Changes 🏗️https://github.com/user-attachments/assets/42e1c896-5f3b-447c-aee9-4f5963c217d9
There is now a 🔔 icon on the Navigation bar that shows previous agent
runs and displays real-time agent running status.
If you run an agent, the bell will show on a badge how many agents are
running. If you hover over it, a hint appears. If you click on it, it
opens a dropdown and displays the executions with their status ( _which
should match what we have in library functionality, not design-wise_ ).
I leveraged the existing APIs for this purpose. Most of the run logic is
[encapsulated on this
hook](https://github.com/Significant-Gravitas/AutoGPT/compare/dev...feat/agent-notifications?expand=1#diff-a9e7f2904d6283b094aca19b64c7168e8c66be1d5e0bb454be8978cb98526617)
and is also an independent `<AgentActivityDropdown />` component.
Clicking on an agent run opens that run in the library page.
This new functionality is covered by E2E tests 💆🏽✔️
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] The navigation bar layout looks good when logged out
- [x] The navigation bar layout looks good when logged in
- [x] Open an agent in the library and click `Run`
- [x] See the real-time activity of the agent running on the navigation
bar bell icon
### For configuration changes:
_No configuration changes needed._
<!-- Clearly explain the need for these changes: -->
### Changes 🏗️
<img width="563" height="400" alt="Screenshot 2025-07-19 at 00 50 25"
src="https://github.com/user-attachments/assets/ce9b2fe3-a244-40ed-a7a9-27b983ec90f2"
/>
Introduced an error on my previous PR:
https://github.com/Significant-Gravitas/AutoGPT/pull/10397 (
`shouldRender` should be taken in account... )
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Login / logout as normal completing challenge
#### For configuration changes:
None
## Changes 🏗️
Do not render the Cloudflare CAPTCHA if the user has already passed
verification.
## Checklist 📋
### For code changes
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Try with Cloudflare enabled
- [x] Shows the CAPTCHA when not verified
- [x] CAPTCHA is hidden when verified
### For configuration changes
None
## Changes 🏗️https://github.com/user-attachments/assets/dd635fa1-d8ea-4e5b-b719-2c7df8e57832
Using [LaunchDarkly](https://launchdarkly.com/), introduce the concept
of "beta" blocks, which are blocks that will be disabled in production
unless enabled via a feature flag. This allows us to safely hide and
test certain blocks in production safely.
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Checkout and run FE locally
- [x] With the `beta-blocks` flag `disabled` in LD
- [x] Go to the builder and see **you can't** add the blocks specified
on the flag
- [x] With the `beta-blocks` flag `enabled` in LD
- [x] Go to the builder and see **you can** add the blocks specified on
the flag
### For configuration changes:
- [x] `.env.example` is updated or already compatible with my changes
🚧 We need to add the `NEXT_PUBLIC_LAUNCHDARKLY_CLIENT_ID` to the dev and
prod environments.
## Changes 🏗️
### User creation tests
Now, all tests use the users created via the platform signup in
`global-setup.ts`. Their login details are on a `.auth/user-pool.json`
file. I have the delete the logic that created tests users via Supabase
directly.
### Build tests speed
I have refactored the builder tests, so that, instead of adding 100s of
blocks under a given test user session, a new test user logins and adds
block for each letter:
```
Test user 1
- logins and adds blocks starting with "a"
Test user 2
- logins and adds blocks starting with "b"
```
Given that we know the builder becomes slow once we have 30 or more
blocks, in this way a test user never adds more than 10 blocks on a
given test ( _without losing coverage_ ), so we don't need time-outs or
artificially waiting due to the UI being slow.
### Readability test changes
Refactor existing tests, using short-hand utilities, to be:
- easier to write
- clearer to read
- easier to debug
```ts
// Selectors
getId("id") // --> page.getByTestId("id")
getText("foo") // --> page.getByText("id")
getButton("Run") // --> page.getByRole("button", {name: "Run"}
...
// Assetions
const btn = getButton("Save")
isVisible(btn) // --> expect(btn).toBeVisible()
```
These utilities live under `selectors.ts` and `assertions.ts`. Their
usage is optional but encouraged.
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Refactored tests code looks good
- [x] E2E tests are 🟢 on the CI
### For configuration changes:
No config changes
This update enhances the performance and user experience by allowing
data to be prefetched, reducing loading times on the frontend.
### Changes
- Introduced `usePrefetch` in Orval configuration to support
prefetching.
- Added prefetch queries for user profiles, admin listings history,
notification preferences, and execution schedules.
- Updated OpenAPI specifications to include descriptions for provider
names and adjusted required fields in request models.
- Enhanced the Navbar component to utilize the new prefetch
functionality for user profile data.
- Improved type definitions for various models to ensure better
integration with the API.
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] I’ve checked everything manually, and everything is working fine.
## Changes 🏗️
- Put `Continue with Google` button below the other button on the forms
( _to confirm with design_ )
- Ensure some vertical spacing so the forms don't end touching the
header on small screens
- Apply style adjustments asked by design on navbar links
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Check the above
### For configuration changes:
None
## Changes 🏗️
Disable the Cloudflare check:
<img width="600" height="861" alt="Screenshot 2025-07-11 at 18 51 46"
src="https://github.com/user-attachments/assets/792ecca0-967e-4cef-a562-789125452d2f"
/>
On Vercel previews, so we can use previews for testing Front-end only
changes.
Vercel previews have dynamically generated URLs:
```
https://{branch}-{commit}-significant-gravitas.vercel.app/login
```
So if Cloudflare does not support URL wildcards we will neeed to do this
🙇🏽 ( _as an experiment_ )
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] You can login on the preview
### For configuration changes:
None
Currently, my agents count is showing the initial agent count loads on
the library and then adding more agents after pagination.
### Changes 🏗️
- I’ve used `total_items` inside the pagination response and shown the
correct result.
### Demo
https://github.com/user-attachments/assets/b9a2cf18-c9fc-42f8-b0d4-3f8a7ad3cbc5
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Manually test everything, and it works fine.
- Resolves#10313
- Resolves#10333
Before:
https://github.com/user-attachments/assets/a105b2b0-a90b-4bc6-89da-bef3f5a5fa1f
- No credentials input
- Stuttery experience when panning or zooming the viewport
After:
https://github.com/user-attachments/assets/f58d7864-055f-4e1c-a221-57154467c3aa
- Pretty much the same UX as in the Library, with fully-fledged
credentials input support
- Much smoother when moving around the canvas
### Changes 🏗️
Frontend:
- Add credentials input support to Run UX in Builder
- Pass run inputs instead of storing them on the input nodes
- Re-implement `RunnerInputUI` using `AgentRunDetailsView`; rename to
`RunnerInputDialog`
- Make `AgentRunDraftView` more flexible
- Remove `RunnerInputList`, `RunnerInputBlock`
- Make moving around in the Builder *smooooth* by reducing unnecessary
re-renders
- Clean up and partially re-write bead management logic
- Replace `request*` fire-and-forget methods in `useAgentGraph` with
direct action async callbacks
- Clean up run input UI components
- Simplify `RunnerUIWrapper`
- Add `isEmpty` utility function in `@/lib/utils` (expanding on
`_.isEmpty`)
- Fix default value handling in `TypeBasedInput` (**Note:** after all
the changes I've made I'm not sure this is still necessary)
- Improve & clean up Builder test implementations
Backend + API:
- Fix front-end `Node`, `GraphMeta`, and `Block` types
- Small refactor of `Graph` to match naming of some `LibraryAgent`
attributes
- Fix typing of `list_graphs`,
`get_graph_meta_by_store_listing_version_id` endpoints
- Add `GraphMeta` model and `GraphModel.meta()` shortcut
- Move `POST /library/agents/{library_agent_id}/setup-trigger` to `POST
/library/presets/setup-trigger`
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- Test the new functionality in the Builder:
- [x] Running an agent with (credentials) inputs from the builder
- [x] Beads behave correctly
- [x] Running an agent without any inputs from the builder
- [x] Scheduling an agent from the builder
- [x] Adding and searching blocks in the block menu
- [x] Test that all existing `AgentRunDraftView` functionality in the
Library still works the same
- [x] Run an agent
- [x] Schedule an agent
- [x] View past runs
- [x] Run an agent with inputs, then edit the agent's inputs and view
the agent in the Library (should be fine)
## Changes 🏗️
<img width="800" alt="Screenshot 2025-07-07 at 13 16 44"
src="https://github.com/user-attachments/assets/0d404958-d4c9-454d-b71a-9dd677fe0fdc"
/>
<img width="800" alt="Screenshot 2025-07-07 at 13 17 08"
src="https://github.com/user-attachments/assets/1142f6d5-a6af-485d-b42e-98afd26de3ed"
/>
Update the UI of the logged-out pages ( _login, signup,
reset-password..._ ) using the new Design System components, so the app
starts to look a bit more cohesive 💆🏽
Some notes:
- I refactored the `<AuthCard />` components a bit to be easier to use
- I split the render from hook login on login/signup
- I added a couple of modals to improve the UX when logging in with
Google or using non-whitelisted emails
- _see below my comments for more context_
- When there are API errors, they are shown in a toast to prevent the
layout of the form from jumping
- When using the components in the UI, an issue with border-radius, see
comments for an explanation
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Logout on the platform
- [x] Check the updated Login/Signup/Reset password pages
- [x] The UI looks good and is consistent
- [x] The forms work as expected
## Changes 🏗️
<img width="900" height="327" alt="Screenshot 2025-07-10 at 20 12 38"
src="https://github.com/user-attachments/assets/044f00ed-7e05-46b7-a821-ce1cb0ee9298"
/>
<br /><br />
Navbar updated to look pretty from the new designs:
- the logo is now centred instead of on the left
- menu items have been updated to a smaller font-size and less radius
- icons have been updated
I also generated the API files ( _sorry for the noise_ ). I had to do
some border-radius and button updates on the atoms/tokens for it to look
good.
## Checklist 📋
## For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Login/logout
- [x] The new navbar looks good across screens
## For configuration changes
No config changes
## Block Development SDK - Simplifying Block Creation
### Problem
Currently, creating a new block requires manual updates to **5+ files**
scattered across the codebase:
- `backend/data/block_cost_config.py` - Manually add block costs
- `backend/integrations/credentials_store.py` - Add default credentials
- `backend/integrations/providers.py` - Register new providers
- `backend/integrations/oauth/__init__.py` - Register OAuth handlers
- `backend/integrations/webhooks/__init__.py` - Register webhook
managers
This creates significant friction for developers, increases the chance
of configuration errors, and makes the platform difficult to scale.
### Solution
This PR introduces a **Block Development SDK** that provides:
- Single import for all block development needs: `from backend.sdk
import *`
- Automatic registration of all block configurations
- Zero external file modifications required
- Provider-based configuration with inheritance
### Changes 🏗️
#### 1. **New SDK Module** (`backend/sdk/`)
- **`__init__.py`**: Unified exports of 68+ block development components
- **`registry.py`**: Central auto-registration system for all block
configurations
- **`builder.py`**: `ProviderBuilder` class for fluent provider
configuration
- **`provider.py`**: Provider configuration management
- **`cost_integration.py`**: Automatic cost application system
#### 2. **Provider Builder Pattern**
```python
# Configure once, use everywhere
my_provider = (
ProviderBuilder("my-service")
.with_api_key("MY_SERVICE_API_KEY", "My Service API Key")
.with_base_cost(5, BlockCostType.RUN)
.build()
)
```
#### 3. **Automatic Cost System**
- Provider base costs automatically applied to all blocks using that
provider
- Override with `@cost` decorator for block-specific pricing
- Tiered pricing support with cost filters
#### 4. **Dynamic Provider Support**
- Modified `ProviderName` enum to accept any string via `_missing_`
method
- No more manual enum updates for new providers
#### 5. **Application Integration**
- Added `sync_all_provider_costs()` to `initialize_blocks()` for
automatic cost registration
- Maintains full backward compatibility with existing blocks
#### 6. **Comprehensive Examples** (`backend/blocks/examples/`)
- `simple_example_block.py` - Basic block structure
- `example_sdk_block.py` - Provider with credentials
- `cost_example_block.py` - Various cost patterns
- `advanced_provider_example.py` - Custom API clients
- `example_webhook_sdk_block.py` - Webhook configuration
#### 7. **Extensive Testing**
- 6 new test modules with 30+ test cases
- Integration tests for all SDK features
- Cost calculation verification
- Provider registration tests
### Before vs After
**Before SDK:**
```python
# 1. Multiple complex imports
from backend.data.block import Block, BlockCategory, BlockOutput
from backend.data.model import SchemaField, CredentialsField
# ... many more imports
# 2. Update block_cost_config.py
BLOCK_COSTS[MyBlock] = [BlockCost(...)]
# 3. Update credentials_store.py
DEFAULT_CREDENTIALS.append(...)
# 4. Update providers.py enum
# 5. Update oauth/__init__.py
# 6. Update webhooks/__init__.py
```
**After SDK:**
```python
from backend.sdk import *
# Everything configured in one place
my_provider = (
ProviderBuilder("my-service")
.with_api_key("MY_API_KEY", "My API Key")
.with_base_cost(10, BlockCostType.RUN)
.build()
)
class MyBlock(Block):
class Input(BlockSchema):
credentials: CredentialsMetaInput = my_provider.credentials_field()
data: String = SchemaField(description="Input data")
class Output(BlockSchema):
result: String = SchemaField(description="Result")
# That's it\! No external files to modify
```
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Created new blocks using SDK pattern with provider configuration
- [x] Verified automatic cost registration for provider-based blocks
- [x] Tested cost override with @cost decorator
- [x] Confirmed custom providers work without enum modifications
- [x] Verified all example blocks execute correctly
- [x] Tested backward compatibility with existing blocks
- [x] Ran all SDK tests (30+ tests, all passing)
- [x] Created blocks with credentials and verified authentication
- [x] Tested webhook block configuration
- [x] Verified application startup with auto-registration
#### For configuration changes:
- [x] `.env.example` is updated or already compatible with my changes
(no changes needed)
- [x] `docker-compose.yml` is updated or already compatible with my
changes (no changes needed)
- [x] I have included a list of my configuration changes in the PR
description (under **Changes**)
### Impact
- **Developer Experience**: Block creation time reduced from hours to
minutes
- **Maintainability**: All block configuration in one place
- **Scalability**: Support hundreds of blocks without enum updates
- **Type Safety**: Full IDE support with proper type hints
- **Testing**: Easier to test blocks in isolation
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Abhimanyu Yadav <122007096+Abhi1992002@users.noreply.github.com>
This plugin helps users organise library pages and use React Query for
data fetching on these pages.
### Changes
- Restructure the component position.
- Divide the component into two parts: one for rendering and the other
for hooks.
- Change data fetching from the normal fetch to an autogenerated React
query.
- Everything is shifted to the client side.
### Important Notes
- I haven’t changed any UI in this. I’ve divided it into sub-parts
because my main focus is on data fetching.
- Edit is not working, so I need to fix it in the follow-up PR. I
haven’t broken it; it broke already.
- I need to fix prop drilling in further PRs.
- I need to fix loading states.
> I haven’t changed the credit page or integration because I’m getting
errors while setting up Stripe for testing. My card is constantly
declined, and the integration page is attached to the builder page. I’ll
add changes to it when I’m working with the builder.
### Checklist 📋
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Tested manually and everything is working perfectly
- [x] Verified agent listing loads correctly
- [x] Confirmed delete functionality works
## Changes 🏗️
If the proxied API call fails with an error that is not JSON-like,
expose it still to the client so it can be shown.
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Login
- [x] Try to top up credits
- [x] You see a better failure on the error toast when redirected back
to the app
---------
Co-authored-by: Abhimanyu Yadav <122007096+Abhi1992002@users.noreply.github.com>
## Changes 🏗️
Fixes the layout getting very wide if the output of an agent is very
long:
https://github.com/user-attachments/assets/e032f425-ed9a-4a13-925f-1bb444f84ef1
It also makes the library agent code a bit more defensive, I get full
page errors on certain agents in the library:
<img width="800" alt="Screenshot 2025-07-04 at 17 35 46"
src="https://github.com/user-attachments/assets/ff8ae461-3792-4e94-941e-9fdd2ead1c87"
/>
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Login and go to agent in library
- [x] It loads without errors
- [x] When the execution output is long, it doesn't make the page wider
## Changes 🏗️
We created a proxy route ( `/api/proxy/...` ) to handle API calls made
in the browser from the legacy `BackendAPI`, ensuring security and
compatibility with server cookies 💆🏽🍪
However, the code on the proxy was written optimistically, expecting the
payload to be present in the JSON requests... even though many requests,
such as `POST` or `PATCH`, can sometimes be fired without a body.
This fixed the issue we saw when stopping a running agent wasn't
working, because to stop it, fires a `PATCH` without a payload.
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Checkout and run this locally
- [x] Login
- [x] Go to Library
- [x] Run agent
- [x] Stop it
- [x] It works without errors
## Changes 🏗️
### Root Cause
With httpOnly cookies, the Supabase client can't automatically exchange
password reset codes for sessions client-side because it can't access
the secure cookies 🍪 ( _which is a good thing_ ).
Previously, when users clicked email reset links, the Supabase client on
the browser would automatically handle the code exchange, but
with`httpOnly`, this is not possible because the Supabase browser client
does not have access to session info, so it fails silently 🥵
### Solution
Moved password reset code exchange to server-side middleware that can
access `httpOnly` cookies and properly create authenticated sessions.
### Code Changes
**`middleware.ts`**
- intercepts `/reset-password` URLs containing `code` parameter
- uses helper function to exchange code for session server-side
- redirects with error parameters if exchange fails
- moved `getUser()` call to avoid middleware timing issues
**`reset-password/page.tsx`**
- added toast notifications for password reset errors
- checks URL parameters for error messages on page load
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Password reset emails send successfully
- [x] Valid reset codes exchange for sessions server-side
- [x] Invalid/expired codes show error messages via toast
- [x] Successfully authenticated users can change passwords
- [x] URL parameters are cleaned up after error display
- [x] Middleware doesn't break normal authentication flows
### For configuration changes:
For this to work we need to configure Supabase with the new
password-reset redirect URL.
```
/api/auth/callback/reset-password
```
- [x] Already added in Supabase dev
- [ ] We need to add it on Supabase prod
- Resolves#10298
- Follow-up to #10270
### Changes 🏗️
Amend two changes from #10270:
- Add fallback for `NEXT_PUBLIC_FRONTEND_BASE_URL` in custom-mutator.ts
- Revert rename of `FRONTEND_BASE_URL` to
`NEXT_PUBLIC_FRONTEND_BASE_URL` in `backend/.env.example`
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- Don't set `NEXT_PUBLIC_FRONTEND_BASE_URL`
- Run the platform locally
- [x] -> `/library` loads normally
#### For configuration changes:
- [x] `.env.example` is updated or already compatible with my changes
- [x] I have included a list of my configuration changes in the PR
description (under **Changes**)
## Changes 🏗️
Requests to the Backend happen now on the server, given we moved to
server-side cookies 🍪 ... however the client proxy is not exposing the
API errors to the client correctly. This aim to fix that.
## Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Login to the platform
- [x] Run agents until you encounter an error
- [x] The error is shown on the toast
## Changes 🏗️
We want to make running the AutoGPT Front-end as easy as possible. For
that, you should be able to run it with the least amount of commands.
We recently added generated queries and types on the Front-end from the
Back-end OpenAPI schema, to make development easier and catch bugs
earlier. However, with the current setup, developers are forced to run
`pnpm generate:api-all` with the Back-end running, which is annoying.
After this PR, the Front-end can be rerun with just `pnpm i & pnpm dev`.
## Checklist 📋
### For code changes
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Run the Front-end with just `pnpm dev` and it works
---------
Co-authored-by: Abhimanyu Yadav <122007096+Abhi1992002@users.noreply.github.com>
### Changes 🏗️
A new undocumented env var, `NEXT_PUBLIC_AGPT_SERVER_BASE_URL`, was
added to the proxy route for it to work with the new `react-query`
mutator.
I removed it and used the existing `NEXT_PUBLIC_AGPT_SERVER_URL`, so we
have fewer environment variables to manage ( _and this one is already
added to all environments_ ).
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Run the server locally
- [x] All pages ( library, marketplace, builder, settings ) work
## Changes 🏗️
We need to `FRONTEND_BASE_URL` to → `NEXT_PUBLIC_FRONTEND_BASE_URL`
given is needed on the new API client on the Front-end to make requests.
The `NEXT_PUBLIC` prefix is important so that it is available on the
client.
## Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Run the app locally
- [x] The library and other pages work
