You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Gnosis SAFE I have a master SAFE and a nested SAFE... I am connected to the nested SAFE - the master SAFE is the only signer of the Nested SAFE as shown in Settings - yet I cannot start a transaction in th enested SAFE as the button is blanked out - it says "your connected wallet is not a signer of this SAFE account" any ideas... it used to work perfectly ...
"This is a known pain point with Gnosis Safe's UI changes. Here's what's likely happening and how to fix it:
The core issue: Safe's UI now requires your externally owned account (EOA) wallet — like MetaMask — to be a direct signer on the Safe you're connected to. When a Safe is a signer of another Safe (nested Safe setup), the UI doesn't always recognize the indirect signing relationship the way it used to.
Things to try:
1. Connect to the Master Safe first, then navigate to the nested Safe Safe updated how it handles nested/delegated signing. Try connecting your wallet while viewing the master Safe, then switching to the nested Safe context. Sometimes the session carries the right permissions over.
2. Check if Safe switched to "Safe{Pass}" or social login They've been pushing a new auth system. If your master Safe's signers were migrated or if you're now logged in via Safe's own auth rather than a raw wallet connection, the signer detection breaks. Make sure you're connecting via WalletConnect or MetaMask directly, not Safe's built-in login.
3. Use the Transaction Builder directly via Apps Go to Apps → Transaction Builder inside the nested Safe. This sometimes bypasses the UI restriction and lets you construct a transaction manually even when the "New Transaction" button is greyed out.
4. Try the Safe old UI or API Safe kept a legacy interface for a while at app.safe.global — check if there's still a "use old app" toggle. Alternatively, use the Safe SDK / API directly to propose a transaction programmatically.
5. Add your EOA as a temporary direct signer If you can still act through the master Safe, use it to add your EOA wallet as a direct signer on the nested Safe (even as a 0-of-N or alongside the master Safe). This is the most reliable fix if the UI change is permanent.
6. Check Safe version In Settings → Safe Account, check the contract version. If it's on an older version and Safe recently pushed UI changes for newer contract features, there can be a mismatch in how signing eligibility is detected.
Most likely culprit: Safe's recent UI update (late 2024/early 2025) tightened the connected wallet validation — it now checks the immediate signer list rather than resolving nested Safe ownership chains. The Transaction Builder workaround (point 3) is your quickest path while you sort out the root cause.
Would you like help constructing a transaction via the SDK/API route, or thinking through how to restructure the signer setup?"
Tried... my response: none of these worked - except 3 which took me to the verge of signing (even showing a successful simulation) but then blanked out the 'Continue' or 'Sign' button to actually launch the approval (with again the message that the connected wallet was not a signer)... However what did work was to sign on their retarded Spaces (beta) project putting both the master ans the nested safe in the same 'Space' ... then suddenly it started talking to each other and worked
Claude >> "That's a really useful find — and it makes sense when you think about what Spaces is actually doing under the hood.
Why Spaces fixed it:
When you add both Safes to the same Space, Safe's frontend finally builds the full ownership graph — it can see that your EOA controls the master Safe, which controls the nested Safe, and it resolves that chain properly. Without that context, the UI was doing a shallow check (is your EOA a direct signer of the nested Safe? No → blocked), rather than a deep check (is your EOA a signer of anything that can sign for the nested Safe? Yes → allow).
Essentially Spaces gave the UI the missing context to traverse the nested relationship.
What this tells us about the regression:
Safe almost certainly broke the nested Safe signer resolution in a UI update — probably when they started building out Spaces and moved ownership/relationship logic into that layer. The old UI must have resolved ownership chains differently (or queried the contract more thoroughly), and at some point that got dropped or gated behind the Spaces feature.
Practical takeaway for anyone else hitting this:
If you have a nested Safe setup (Safe-as-signer), put both Safes in a Safe Space — even a throwaway one — and the UI will correctly recognise the indirect signing relationship.
Annoying that it's not documented anywhere and requires opting into a beta feature just to restore functionality that used to work by default. Worth flagging to Safe's support so they're aware it's a silent regression rather than intentional behaviour."
Today's date: 2026-07-31
🤖 Refined and Investigated by Claude — 2026-07-31
Session: Wallet Hygiene cloud routine, run 2026-07-31 (batch 4/6)
Labels added: Type → Bug, Tech → Frontend
Investigation notes:
Code: searched for isNestedSafeOwner/nestedSafeOwners/isSignerOfNestedSafe-style symbol names in safe-wallet-monorepo — no hits, so the actual signer-eligibility check likely uses different naming (e.g. an ownership-graph or useIsSafeOwner-style hook); could not pinpoint the exact file within the search budget for this ticket.
Reproduce: connect an EOA that is a signer only of a Master Safe, view a Nested Safe where the Master Safe is the sole owner, confirm "New transaction" is disabled with a "not a signer" message
Confirm whether joining a Space (multi-Safe grouping) changes signer-eligibility resolution, or whether that was coincidental
If confirmed, fix the eligibility check to resolve indirect/nested ownership without requiring Spaces
Unclear/missing: single user's anecdotal account with a workaround, not an engineer-confirmed root cause; needs confirmation that nested-Safe signer resolution actually depends on Spaces membership.
Flagged for a human: (1) ticket has been in Backlog status for ~74 days (>30d) without further triage; (2) existing "Flex" label doesn't map to any group in the current Type/Tech/Features taxonomy — left as-is since it isn't in a conflicting single-select group.
Auto-generated best-effort draft. Edit freely. React 👎 on this issue or ping to flag misses so I learn.
In Gnosis SAFE I have a master SAFE and a nested SAFE... I am connected to the nested SAFE - the master SAFE is the only signer of the Nested SAFE as shown in Settings - yet I cannot start a transaction in th enested SAFE as the button is blanked out - it says "your connected wallet is not a signer of this SAFE account" any ideas... it used to work perfectly ...
"This is a known pain point with Gnosis Safe's UI changes. Here's what's likely happening and how to fix it:
The core issue: Safe's UI now requires your externally owned account (EOA) wallet — like MetaMask — to be a direct signer on the Safe you're connected to. When a Safe is a signer of another Safe (nested Safe setup), the UI doesn't always recognize the indirect signing relationship the way it used to.
Things to try:
1. Connect to the Master Safe first, then navigate to the nested Safe
Safe updated how it handles nested/delegated signing. Try connecting your wallet while viewing the master Safe, then switching to the nested Safe context. Sometimes the session carries the right permissions over.
2. Check if Safe switched to "Safe{Pass}" or social login
They've been pushing a new auth system. If your master Safe's signers were migrated or if you're now logged in via Safe's own auth rather than a raw wallet connection, the signer detection breaks. Make sure you're connecting via WalletConnect or MetaMask directly, not Safe's built-in login.
3. Use the Transaction Builder directly via Apps
Go to Apps → Transaction Builder inside the nested Safe. This sometimes bypasses the UI restriction and lets you construct a transaction manually even when the "New Transaction" button is greyed out.
4. Try the Safe old UI or API
Safe kept a legacy interface for a while at
app.safe.global— check if there's still a "use old app" toggle. Alternatively, use the Safe SDK / API directly to propose a transaction programmatically.5. Add your EOA as a temporary direct signer
If you can still act through the master Safe, use it to add your EOA wallet as a direct signer on the nested Safe (even as a 0-of-N or alongside the master Safe). This is the most reliable fix if the UI change is permanent.
6. Check Safe version
In Settings → Safe Account, check the contract version. If it's on an older version and Safe recently pushed UI changes for newer contract features, there can be a mismatch in how signing eligibility is detected.
Most likely culprit: Safe's recent UI update (late 2024/early 2025) tightened the connected wallet validation — it now checks the immediate signer list rather than resolving nested Safe ownership chains. The Transaction Builder workaround (point 3) is your quickest path while you sort out the root cause.
Would you like help constructing a transaction via the SDK/API route, or thinking through how to restructure the signer setup?"
Tried... my response: none of these worked - except 3 which took me to the verge of signing (even showing a successful simulation) but then blanked out the 'Continue' or 'Sign' button to actually launch the approval (with again the message that the connected wallet was not a signer)... However what did work was to sign on their retarded Spaces (beta) project putting both the master ans the nested safe in the same 'Space' ... then suddenly it started talking to each other and worked
Claude >>
"That's a really useful find — and it makes sense when you think about what Spaces is actually doing under the hood.
Why Spaces fixed it:
When you add both Safes to the same Space, Safe's frontend finally builds the full ownership graph — it can see that your EOA controls the master Safe, which controls the nested Safe, and it resolves that chain properly. Without that context, the UI was doing a shallow check (is your EOA a direct signer of the nested Safe? No → blocked), rather than a deep check (is your EOA a signer of anything that can sign for the nested Safe? Yes → allow).
Essentially Spaces gave the UI the missing context to traverse the nested relationship.
What this tells us about the regression:
Safe almost certainly broke the nested Safe signer resolution in a UI update — probably when they started building out Spaces and moved ownership/relationship logic into that layer. The old UI must have resolved ownership chains differently (or queried the contract more thoroughly), and at some point that got dropped or gated behind the Spaces feature.
Practical takeaway for anyone else hitting this:
Annoying that it's not documented anywhere and requires opting into a beta feature just to restore functionality that used to work by default. Worth flagging to Safe's support so they're aware it's a silent regression rather than intentional behaviour."
Today's date: 2026-07-31
🤖 Refined and Investigated by Claude — 2026-07-31
Session: Wallet Hygiene cloud routine, run 2026-07-31 (batch 4/6)
Labels added: Type → Bug, Tech → Frontend
Investigation notes:
isNestedSafeOwner/nestedSafeOwners/isSignerOfNestedSafe-style symbol names in safe-wallet-monorepo — no hits, so the actual signer-eligibility check likely uses different naming (e.g. an ownership-graph oruseIsSafeOwner-style hook); could not pinpoint the exact file within the search budget for this ticket.Flagged for a human: (1) ticket has been in Backlog status for ~74 days (>30d) without further triage; (2) existing "Flex" label doesn't map to any group in the current Type/Tech/Features taxonomy — left as-is since it isn't in a conflicting single-select group.
Auto-generated best-effort draft. Edit freely. React 👎 on this issue or ping to flag misses so I learn.