Feature Request

When editing a script and starting it from the editor page, I'm brought to the current job. If I click the back button next to the job number, it would be nice to be directed back to the editor instead of the jobs overview page. [image]

It would be nice to get an email with the changes whenever there is a new PSU release, and maybe even have an RSS feed for automated tools to keep track of releases.

We use the manual git push mode, so when we click "Commit Changes" in the top menu we get to the page where we choose which files to commit. This page is very good to see all changes, but has one little problem: The right hand side of the page (the part actually showing the changes) doesn't reflect which files are actually marked for commit in the left hand panel. It would be extremely useful if I could mark only the files I actually want to commit and then only those changes would be displayed. On a side note: The ordering of files in the views (ie the files to change and the view showing the actual changes) doesn't really match, so sometimes it's hard to find which file in the right hand side matches a specific file in the left hand side. I don't know if this is a bug or intended behaviour. I'm currently on 2026.3.0. /Daniel

It would be nice to have some kind of variable or cache availability in published folder files. I know that technically you could just set up an API endpoint, but I still would like it in other ways.

With how many bugs have been in the 2026.3.x releases, I think it would be beneficial to have a public beta channel so releases can be tested and bugs can be identified before being pushed to production.

It would be nice to have the ability to download files from the files tab, as well as being able to select multiple and download them all at the same time.

Hi. I just got an idea... Every day me and my collegues go through failed jobs in PSU and it's always hard to keep track on which jobs have been looked at and not. Would it be possible to add functionality to somehow "check off" jobs? Or maybe write a comment in them, like "Problem was that provider X was temporarily unreachable, will work again at next run" or "Problem was bug in script, corrected at line Y"? This would be immensely useful for me and my team! /Daniel

Hello, I'm a huge fan of Microsoft Learn's MCP and would love a public, read-only, version-aware MCP server for PowerShell Universal documentatio too. I created one for dbatools at https://dbatools.io/mcp/ and it's been surprisingly effective (tho i dont version yet) I realize PSU has MCP support built in now too, but that seems more oriented toward understanding and interacting with a running PSU instance than serving the documentation itself. (Maybe I'm wrong?) I also found the GitBook MCP at https://docs.devolutions.net/~gitbook/mcp , but it doesn't appear to support scoping queries to a specific PSU version. Since PSU can change dramatically between versions, version-aware search and page retrieval would be especially useful. Thank you for your consideration.

I the previous version of PSU we used the /api/v1/health/status endpoint to report issues on our Zabbix dashboard. It would appear that with the new version the CPU health check is triggering a high CPU utilization warning/error almost every time it runs. It would be nice if we could filter out those health alerts via API parameters and/or disable specific health checks completely.

There doesn't seem to be a parameter for "System" yet, and using the API directly I can't seem to create a system identity or token at all.

Enable AI Agents to Access AI Tools and MCP Servers Across Multiple PowerShell Universal Instances Currently, AI Agents in PowerShell Universal can only use AI Tools that are available on their local PSU instance. This limitation makes it difficult to build AI-driven workflows that span multiple specialized PSU environments. I would like to request support for cross-server AI Tool discovery and execution , preferably by allowing AI Agents to consume MCP (Model Context Protocol) servers from other PowerShell Universal instances. Proposed Solution Allow administrators to register remote MCP servers and/or remote AI Tool providers from other PSU instances and expose them to local AI Agents as if they were native tools. Possible implementation options: Register one or more remote MCP servers per PSU instance. Allow AI Agents to access tools published by trusted remote MCP servers. Support authentication, authorization, and tool scoping for remote resources. Provide the option to selectively expose AI Tools across PSU environments. Example Use Case We operate two dedicated PowerShell Universal environments: FW-PSU : Firewall management and firewall-related automation SM-PSU : Service management and service request processing A typical workflow involves service requests for new firewall rules. Today, the process looks like this: An AI Agent runs on SM-PSU . The agent uses a local AI Tool to extract IP addresses and FQDNs from the service request. The agent invokes another local AI Tool that calls a custom API exposed by FW-PSU . That API determines the corresponding firewall objects and returns the results. The agent then uses another local AI Tool to generate comments or enrich the service request. This requires additional custom API endpoints solely to bridge the gap between the two PSU environments. Expected Benefit If MCP servers from multiple PSU instances could be connected and made available to AI Agents, the agent on SM-PSU could directly use firewall-related tools hosted on FW-PSU . Benefits include: Reduced integration complexity Elimination of custom API bridge endpoints Better separation of responsibilities between PSU instances Improved reuse of existing AI Tools Faster implementation of cross-domain AI workflows More scalable architecture for organizations operating multiple PSU environments Example Instead of: SM Agent → Local Tool → Custom FW API → FW Logic → Local Tool The workflow could become: SM Agent → Remote FW MCP Tool → Result This would provide a cleaner and more maintainable architecture while leveraging the existing MCP ecosystem and AI Tool framework within PowerShell Universal. Business Value Organizations often deploy multiple PowerShell Universal instances that are responsible for different operational domains such as Service Management, Identity Management, Firewall Management, Cloud Operations, or Infrastructure Automation. Enabling AI Agents to consume remote MCP servers and AI Tools would significantly improve interoperability between these environments and reduce the need for custom integration layers.

Update doc: https://docs.github.com/en/rest?apiVersion=2026-03-10 With things from here: https://github.com/settings/personal-access-tokens https://docs.github.com/en/rest?apiVersion=2026-03-10 To walk through a github copilot api setup, i guess it would be in the 'custom' category, but a copilot category might be better so we do not have to guess what the URL's and other values are.

The documentation for PSU management cmdlets should state the exact permission required by the access token. For example, Get-PSUPublishedFolder fails with a token assigned to the built-in Reader role but succeeds with an Administrator token. Neither the cmdlet documentation nor the Published Folders documentation identifies the required permission. Please document: The exact permission required for each management cmdlet, e.g. Get-PSUPublishedFolder. A least-privilege token example for each cmdlet. This would allow administrators to create purpose-specific service tokens instead of granting the Administrator role.

With the new layout of 2026.3, it'd be great if we could pin menu items in the space at the top of the left side menu bar and make it a bit more customized. [image]

Problem When adding a PSU MCP server in VS Code, the connection can be configured either by manually adding /api/v1/mcp to the mcp.json configuration or by using the extension's server connection feature, which automatically appends the endpoint. In both cases, the resulting MCP server connection is automatically named Universal.Server . As a consequence, multiple PSU MCP server connections appear with the same name, making it impossible to distinguish between them in the VS Code UI. Expected Behavior The displayed MCP server name should be configurable or automatically derived from the target server information. Possible approaches: Allow specifying a custom display name in the mcp.json configuration. Use the server hostname as the default connection name. Fall back to the current Universal.Server name only when no custom name or hostname is available. Current Behavior All PSU MCP server connections are displayed as Universal.Server, regardless of the configured endpoint or host. [image] Impact Users managing multiple PSU MCP server instances cannot easily identify which connection belongs to which environment (e.g. Development, Test, Production) or host, increasing the risk of connecting to the wrong server. Benefits Easier management of multiple MCP server connections Better usability and visibility within VS Code Reduced risk of connecting to the wrong environment Consistent behavior with other tools that support custom connection names [image]

Hi there, is it possible to update the button possibilities (Icon button) like MUI website? [image] best regards

the server settings has been moved from the right bar to the profile dropdown. this would make better sense under manage on the right next to all the other things you can toggle.

I've played with workflows some and have a decent grasp of $PSUItem and $Workflow. I haven't managed to get the "Deconstruct hashtable output" to anything that I can discern. Any chance you can add some documentation to show what that setting does?

We rely heavily on Git manual mode, but the Edit/Save toggle in the header bar only appears for full platform Administrators . We've tried every permission combination we could find related to Git, without success. The Edit/Save buttons simply never render for non-admin users. Is it possible to introduce a permission (or permission set) that grants Git edit/commit capability without requiring full platform Administrator rights? [image] [image] Use case: As an administrator, I'd like others on my team, who are intentionally not platform admins, to be able to edit and commit changes to Git. All of our changes promote from Test to Prod via GitHub PRs, so we'd like non-admins to be able to commit in manual mode to stage their PRs. One thing we noticed: if a non-administrator is granted the settings.git.commit/* permission, they can reach the commit page that the "Save" button navigates to (/admin/settings/git/commit) and submit changes there, but they cannot initiate Edit mode, because the Edit/Save buttons never appear for them. Could this capability be tied to (or piggybacked on) the settings.git.commit/* permission so it also surfaces the Edit/Save controls?

Spawned from https://forum.devolutions.net/topics/55354/mcp-tools-high-cpu-load To combat high loads caused by jobs spawned MCP tools, it would also be a good idea to be able to configure Computer Groups and Enviroments where the MCP tools are allowed to start jobs.

Spawned from https://forum.devolutions.net/topics/55354/mcp-tools-high-cpu-load To prevent abuse, denial-of-service or simple overloading it would be prudent to be able to configure rate limiting and/or concurrency settings for MCP tools. The settings should be central and not on a per-script basis.

I have a complex user case where I want collapsible nested content, and also want to store the open/closed state so I can respect them next time the user loads the app. I'd prefer to use expansion panels, but in order to do this I need to know when someone clicks to expand or collapse the element. There's currently no -OnClick for New-UDExpansionPanel, but there is for New-UDListItem with Children. I have it working with list items for now (no custom functions for clarity): New-UDPage -Url 'Example' -Name 'Example' -Content { [bool]$lstLbl1Open = if ($null -eq $Cookies.cLstLbl1 ) { $true } else { [System.Convert]::ToBoolean($Cookies.cLstLbl1) } [bool]$lstLbl2Open = if ($null -eq $Cookies.cLstLbl2 ) { $true } else { [System.Convert]::ToBoolean($Cookies.cLstLbl2) } New-UDList -Dense -Content { New-UDListItem -Id 'lstLbl1' -Label 'Example List Item 1 Parent' -Children { New-UDListItem -Label 'Example List Item Child' } -Open:$lstLbl1Open -OnClick { $lstLbl1Open = -not (Get-UDElement -Id 'lstLbl1').Open Set-UDElement -Id 'lstLbl1' -Attributes @{ Open = $lstLbl1Open } # https://forum.devolutions.net/topics/52958/get-and-set-cookies Invoke-UDJavaScript " // Build the expiration date string: var expiration_date = new Date(); var cookie_string = ''; expiration_date.setFullYear(expiration_date.getFullYear() + 1); // Build the set-cookie string: cookie_string = 'cLstLbl1=$lstLbl1Open; path=/; expires=' + expiration_date.toUTCString(); // Create or update the cookie: document.cookie = cookie_string;" } New-UDListItem -Id 'lstLbl2' -Label 'Example List Item 2 Parent' -Children { New-UDListItem -Label 'Example List Item Child' } -Open:$lstLbl2Open -OnClick { $lstLbl2Open = -not (Get-UDElement -Id 'lstLbl2').Open Set-UDElement -Id 'lstLbl2' -Attributes @{ Open = $lstLbl2Open } # https://forum.devolutions.net/topics/52958/get-and-set-cookies Invoke-UDJavaScript " // Build the expiration date string: var expiration_date = new Date(); var cookie_string = ''; expiration_date.setFullYear(expiration_date.getFullYear() + 1); // Build the set-cookie string: cookie_string = 'cLstLbl2=$lstLbl2Open; path=/; expires=' + expiration_date.toUTCString(); // Create or update the cookie: document.cookie = cookie_string;" } } } -AutoInclude

This is a request for a new Table feature to support a row click function that allows calling an endpoint (running commands) and is spawned from this item on the support form: UDTable On Row Click - Devolutions Forum Essentially, it would be nice to support clicking anywhere in a table row to then perform some function, whether it be navigate to a new page based off data in the row, popping up a modal, or other options. This would help generate more interactive/dynamic pages and make things cleaner than the current options (configuring a clickable button per row). The example I provided is as follows, which would pop up a modal displaying additional details on the row clicked: New-UDTable -LoadData { $Data } -Columns @( New-UDTableColumn -IncludeInExport -Id Id -Property Id -Title "Id" -Width 50 New-UDTableColumn -IncludeInExport -Id ServerName -Property ServerName -Title "Server Name" -Width 150 New-UDTableColumn -IncludeInExport -Id CPUS -Property CPUS -Title "CPUs" New-UDTableColumn -IncludeInExport -Id Memory_GB -Property Memory_GB -Title "Memory (GB)" New-UDTableColumn -IncludeInExport -Id OperatingSystem -Property OperatingSystem -Title "Operating System" -Width 100 ) -OnRowClick { Show-UDModal -FullWidth -Content { New-UDCard -Content { New-UDGridLayout -Content { $VMData = Invoke-PSUEndpoint -Integrated -Url "/api/v1/VM/$($EventData.Id)" | ConvertFrom-Json New-UDTextbox -Id 'Id' -Label 'Id' -Value $EventData.Id -Disabled New-UDTextbox -Id 'ComputerName' -Label 'ComputerName' -Value $EventData.ServerName -Disabled New-UDTextbox -Id 'Department' -Label 'Department' -Value $VMData.Department -Disabled New-UDTextbox -Id 'Owner' -Label 'Owner' -Value $VMData.Owner -Disabled New-UDTextbox -Id 'State' -Label 'State' -Value $VMData.State -Disabled } } } }

[image]

[image] I think it would be nice to see how large a specific cache item is in the DB. for example how large is your dataset for something like caching all ad user objects