It's not entirely clear to me what you mean. Do you want to restore the context after processing the ISR? Or do you want to access the context in the ISR?

If you just want to restore it in the ISR, that can be done with the retfie (Return from interrupt) command. More information can be found in these slides, especially on page 11.

If you want to access the context from within the ISR, that might be possible, depending on your exact situation. Have a look at section 10.9 of the PIC18F4620 datasheet (I just took one randomly, check your specific datasheet as well):

During interrupts, the return PC address is saved on the stack. Additionally, the WREG, STATUS and BSR registers are saved on the Fast Return Stack. If a fast return from interrupt is not used (see Section 5.3 “Data Memory Organization”), the user may need to save the WREG, STATUS and BSR registers on entry to the Interrupt Service Routine.

I believe "Section 5.3" should really be "Section 5.1.3". If you look there:

A Fast Register Stack is provided for the STATUS, WREG and BSR registers, to provide a “fast return” option for interrupts. The stack for each register is only one level deep and is neither readable nor writable. It is loaded with the current value of the corresponding register when the processor vectors for an interrupt. All interrupt sources will push values into the stack registers. The values in the registers are then loaded back into their associated registers if the RETFIE, FAST instruction is used to return from the interrupt.

As you can see, if the Fast Register Stack is used, you cannot recover the context within the ISR. In the rest of this section it's explained when the Fast Register Stack is not used:

If both low and high-priority interrupts are enabled, the stack registers cannot be used reliably to return from low-priority interrupts. [...] In these cases, users must save the key registers in software during a low-priority interrupt.

So if it's possible in your current setup to enable both priorities (or it is already like this), the PIC doesn't do context saving by itself and you have to do it yourself. That means you have full control over the context.

This answer was written for an older version of the question. From the comments to this answer the intention of the OP became clear, making this answer invalid.

It's not entirely clear to me what you mean. Do you want to restore the context after processing the ISR? Or do you want to access the context in the ISR?

If you just want to restore it in the ISR, that can be done with the retfie (Return from interrupt) command. More information can be found in these slides, especially on page 11.

If you want to access the context from within the ISR, that might be possible, depending on your exact situation. Have a look at section 10.9 of the PIC18F4620 datasheet (I just took one randomly, check your specific datasheet as well):

During interrupts, the return PC address is saved on the stack. Additionally, the WREG, STATUS and BSR registers are saved on the Fast Return Stack. If a fast return from interrupt is not used (see Section 5.3 “Data Memory Organization”), the user may need to save the WREG, STATUS and BSR registers on entry to the Interrupt Service Routine.

I believe "Section 5.3" should really be "Section 5.1.3". If you look there:

A Fast Register Stack is provided for the STATUS, WREG and BSR registers, to provide a “fast return” option for interrupts. The stack for each register is only one level deep and is neither readable nor writable. It is loaded with the current value of the corresponding register when the processor vectors for an interrupt. All interrupt sources will push values into the stack registers. The values in the registers are then loaded back into their associated registers if the RETFIE, FAST instruction is used to return from the interrupt.

As you can see, if the Fast Register Stack is used, you cannot recover the context within the ISR. In the rest of this section it's explained when the Fast Register Stack is not used:

If both low and high-priority interrupts are enabled, the stack registers cannot be used reliably to return from low-priority interrupts. [...] In these cases, users must save the key registers in software during a low-priority interrupt.

So if it's possible in your current setup to enable both priorities (or it is already like this), the PIC doesn't do context saving by itself and you have to do it yourself. That means you have full control over the context.